Salsa¶

What is SLSA¶

SLSA is short for Supply chain Levels for Software Artifacts pronounced salsa.

It is a security framework, essentially a checklist comprising standards and controls aimed at preventing tampering, enhancing integrity, and securing both packages and infrastructure within our projects.

SLSA in NAIS¶

If you utilize the nais/docker-build-push action for building and pushing your container image, you will automatically receive a signed attestation/SBOM (Software Bill of Materials) for your container image and its dependencies. This SBOM will be uploaded to your container registry along with your image. The attestation is generated by the Trivy GitHub action and signed using cosign.

Upon deploying your image to NAIS, the attestation will undergo verification by the NAIS platform (picante) and will be uploaded to an SBOM analysis platform known as Dependency-Track. In Dependency-Track, you can examine the attestation as well as the vulnerabilities present in your image and its dependencies.

Usage¶

Simply add nais/docker-build-push to your workflow.

 - uses: nais/docker-build-push@v0
   id: docker-push
   with:
     team: myteam # required
     salsa: true # optional, defaults to true
     project_id: ${{ vars.NAIS_MANAGEMENT_PROJECT_ID }} # required, but is defined as an organization variable
     identity_provider: ${{ secrets.NAIS_WORKLOAD_IDENTITY_PROVIDER }} # required, but is defined as an organization secret
     # ... other options removed for readability

Opt-out

Opt-out from salsa

If you want to opt-out from salsa you can set the salsa input to false

salsa: false

See nais/docker-build-push for more options.

Console and Team management of Vulnerabilities¶

Vulnerabilities is aggregated to the team level, and can be viewed in the Console. Teams can visit the Console to view their Application vulnerabilities, for example:
https://console.nav.cloud.nais.io/team/[team]/vulnerabilities

View and analyze dependencies in Dependency-Track¶

Dependency-Track has a single instance that controls all clusters, and it contains both attestations and vulnerabilities for all signed attestations deployed, except those that have chosen to opt out from salsa. You can access the Dependency-Track user interface through the following URL:

https://salsa.nav.cloud.nais.io

To sign in, utilize the OpenID button, which will redirect you to your organization's identity provider.

Within Dependency-Track, each container in a deployment is associated with its own project. The project's name is composed of the cluster, team name, application name, and/or the container name. You can conduct searches within projects using the following tags:

Team
Application
Image

Below is a screenshot of a project utilizing the dependency graph within Dependency-Track:

Dependency Graph

Dependency-Track has a ton of features so check out the documentation for more information.

Language support¶

SBOM generation for different languages/build tools are dictated by Trivy

Known limitations and alternatives¶

Due to Trivy, you'll receive a streamlined graph of dependencies. This is attributed to Trivy lacking support for Gradle's or Maven's dependency resolution. However, the advantage lies in obtaining both the image dependencies and their associated vulnerabilities.

Trivy directly parses the .jar files, lacking access to the dependency resolution information. Here are two alternative approaches:

Alternative 2, Generate your own Gradle dependencies.

Gradle and Maven plugins for a deep graph of nested transitive dependencies.

Gradle

Add the following plugin to your build.gradle* file.

    id("org.cyclonedx.bom") version "1.7.4"

In your workflow you can generate a SBOM with the following gradle task command:

    - name: Generate and output SBOM
      run: ./gradlew cyclonedxBom

The SBOM will be default located at build/reports/bom.json. Pass the SBOM to the nais/docker-build-push action with the following input:

    uses: nais/docker-build-push@v0
    with:
      byosbom: build/reports/bom.json

For more info about settings check out the CycloneDx Gradle Plugin

Maven

Add the following to your pom.xml file.

    <plugins>
        <plugin>
            <groupId>org.cyclonedx</groupId>
            <artifactId>cyclonedx-maven-plugin</artifactId>
            <executions>
                <execution>
                    <phase>package</phase>
                    <goals>
                        <goal>makeAggregateBom</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>
    </plugins>

In your workflow you can generate a SBOM with the following maven command:

    - name: Generate and output SBOM
      run: ./mvnw package

The SBOM will be default located at target/bom.json. Pass the SBOM to the nais/docker-build-push action with the following input:

    uses: nais/docker-build-push@v0
    with:
      byosbom: target/bom.json

For more info about settings check out the CycloneDx Maven Plugin

Use nais/attest-sign directly¶

When employing the nais/attest-sign action, you can provide the SBOM to the action using the following input:

    uses: nais/attest-sign@v1.x.x
    with:
      sbom: path/to/bom.json

FAQ¶

Project exists in Dependency-Track, but I can't see the SBOM or vulnerabilities¶

This issue likely arises from using the GitHub dependencies graph resolution output JSON as an input for byosbom. The format of this JSON is incompatible with Dependency-Track, please use the SBOM generated nais/docker-build-push action instead or any of the alternatives mentioned above.

This can be fixed by removing from your workflow the similar input:

    byosbom: dependency-graph-reports/deploy-build.json