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 (slsa-verde) 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
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-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 flattened 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.
In your workflow you can generate a SBOM with the following gradle task command:
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:
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:
The SBOM will be default located at target/classes/META-INF/sbom/application.cdx.json
. Pass the SBOM to the nais/docker-build-push
action with the following input:
Use nais/attest-sign directly¶
When employing the nais/attest-sign action
, you can provide the SBOM to the action using the following input:
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: