|
|
# VAT Alternative
|
|
|
|
|
|
|
|
|
|
|
|
### The Problem
|
|
|
|
|
|
When deploying a software factory, there are many hats/personas that interact with the environment in different ways:
|
|
|
|
|
|
* Developers - Upload code that is being proposed for release. The Software factory that's being hosted by the end user will provide pipelines that build and scan the images. The developer will have to remediate or justify any vulnerabitlies in their images in order to meet the security requirements dictated by the security team in charge of the platform. This may be from their own code base, or 3rd party (non IronBank Approved) software.
|
|
|
|
|
|
* Platform Engineers - Platform Engineers may require additional software to deploy and configure the Software Factory or system to meeting operational and/or security requirements. These peices of software may or may not Application owners who may deploy third party components as part of their application architecture.
|
|
|
|
|
|
* Security - The Security Team will need to review all vulnerabilties in the system and associated justifications to provide indivdual assessment for each that the vulnerability is either accepted or properly justified. If not, more information is required from the platform engineer or developer proposing to use the software.
|
|
|
|
|
|
|
|
|
### One Workflow
|
|
|
|
|
|
|
|
|
```mermaid
|
|
|
graph LR
|
|
|
subgraph cicd[Developer CICD]
|
|
|
C[Code+VEX] --> Build
|
|
|
Build --> Scan
|
|
|
Scan --> Check
|
|
|
C --> Check[Check all Vulns have a justification]
|
|
|
Check --> Upload[Upload Image + Justifications]
|
|
|
|
|
|
end
|
|
|
Upload --> OCIRegistry
|
|
|
Scan2 --> OCIRegistry
|
|
|
OCIRegistry --> B[System Vulnerabilities]
|
|
|
B -->|Review/Accept by Security| B
|
|
|
V --> B
|
|
|
subgraph infra[Infra CICD]
|
|
|
GitChanges[GitOps Changes + VEX] --> Scan2[Scan]
|
|
|
Scan2 --> S[Upload Image + VEX]
|
|
|
S --> V[Validate Accepted Justifications]
|
|
|
V --> Prod[Deploy to Environment]
|
|
|
end
|
|
|
```
|
|
|
|
|
|
#### Developer CICD
|
|
|
|
|
|
In this workflow, development teams have access to a Pipeline that automates the building and scanning of their developer images. The peopeline will then upload both the Image (and sbom/signature/etc) to an OCI registry along with a "Justification" Manifest e.g. via a [Vulnerability Exploitability Exchange](https://www.ntia.gov/files/ntia/publications/vex_one-page_summary.pdf) (VEX).
|
|
|
|
|
|
The pipeline will require a reference to a System/organization policy that defines what vulnerabilities need justification and which do not in order to upload the Image/VEX to the OCI registry (e.g. all high's and criticals require justificaitons).
|
|
|
|
|
|
The `Upload Image + Justification` section could return the current status of whether the justificaitons provided by the developer's VEX files have been accepted by the Security team to allow them to better iterate on their process before submitting a request to change the infrastructure.
|
|
|
|
|
|
#### Infra CICD
|
|
|
|
|
|
The Vulnerability Justifications need to be accepted before a change to the runtime. The "Infra CICD" pipeline ensures this. The first stages of the Infra Pipline assess the changes to the proposed infrastructure and identify all the images that will be deployed, using standardized formats like a Zarf config, or [Helm Annotations](https://github.com/helm/community/blob/main/hips/hip-0015.md#specification). The infra pipeline would then scan the needed images, push any attached VEX Attestations and any infra provided VEX files that would be supplied by the infra team. The last step before deploying to the environment would be to ensure that enough of the proposed VEX supplied justifications are accepted by the security team to meet the organization policy. This may end up being *all* the justifications, but some flexibility would be required based on different use cases.
|
|
|
|
|
|
#### Review/Accept by Security
|
|
|
|
|
|
There needs to be a process/tool that the security team can
|
|
|
* See all components in the system
|
|
|
* Review justifications provided by CICD
|
|
|
* Provide feedback when things aren't accepted that can be viewed in the tool, or as part of the CICD job when the components being used fail to meet the acceptance criteria of the security team.
|
|
|
|
|
|
### Big Bang Packages + Iron Bank ABCs
|
|
|
|
|
|
* With the shift to IronBank ABCs, only Big Bang core packages will come with Ironbank reviewed Justifications
|
|
|
|
|
|
* By providing a standard VEX file to the BigBang package, we could provide a mechanism for Third Party Big Bang package owners to provide justifications for the vulnerabilities in their images that could be used by platform teams as a baseline for jumpstarting their acceptance in systems consuming them.
|
|
|
|
|
|
|
|
|
### Relationship to other Items
|
|
|
|
|
|
* Pipelines as Product - when we can ship pre-built pipelines that work out of the box, a stage that uploads this would be ideal.
|
|
|
* CLI tools - Given a product we choose for the System Vulnerability Review, a CLI tool to properly consume scan results from Anchore/Twistlock/Etc and upload to the chosen tool, and then attach the VEX to the associated vulnerability for each tool would be important for workflows.
|
|
|
|
|
|
|
|
|
### Toosl that may work
|
|
|
|
|
|
- https://dependencytrack.org/
|
|
|
- https://nucleussec.com/
|
|
|
- https://www.defectdojo.org/
|
|
|
|
|
|
|