UNCLASSIFIED - NO CUI

Skip to content
Snippets Groups Projects

vat

Last edited by Tom Runyon

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

graph LR
    subgraph cicd[Developer CICD]
        C[Code+Justifications] --> Build
        Build --> Scan
        Scan --> Check
        C --> Check[Check all Vulns have a justification]
        Check --> Upload[Upload Image + Justifications]

    end
    Upload --> OCIRegistry
    S --> OCIRegistry
    OCIRegistry --> B[System Vulnerabilities]
    B -->|Review/Accept by Security| B
    V --> B
    subgraph infra[Infra CICD]
        GitChanges[GitOps Changes + Justifications] --> Scan2[Scan]
        Scan2 --> S[Upload Image + Vulns + Justifications]
        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 (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. 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, some IronBank images will not come with justifications for the vulnerabilities that were idtentified. The images that don't have justifications will be marked as non-compliant but still available on IronBank. The justifications provided to BigBang images will not only be necessary, but also reviewed by IronBank security personell, which may provide additional insight/context on the justifications for the end user ISO to use in their determination.

  • IronBank could provide, as an attestation on the image, the justifications in a standardized format for transfer into third party systems via Zarf.

  • Its important to tie the VEX justifications to specific SBOMs since justifications are specific to how certain components use dependencies.

Relationship to other Items

  • Pipelines as Product - when we can ship pre-built pipelines that work out of the box, a stage that generates these for new containers and uploads these for IronBank/external images would need to be part of the product.
  • 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.
  • VEX Spec: https://cyclonedx.org/docs/1.4/json/

Toosl that may work

Comments

    Please register or sign in to add a comment.

    UNCLASSIFIED - NO CUI