The SLSA Security Framework and IBM DevOps Deploy

Author: Randall Langehennig, November 14, 2024

What is SLSA?

What is SLSA?  SLSA is short for ‘Supply-chain Levels for Software Architects’ and it is often referred to as “salsa” in conversation.   It’s a security framework, a checklist of standards and controls to prevent tampering, improve integrity, and secure packages and infrastructure.   It’s how you get from “safe enough” to being as resilient as possible, at any link in the chain.

Here is an example of the supply-chain:

IBM DevOps Deploy lives in the Distribution space as shown above.   To learn more about SLSA, please refer to this link:  https://slsa.dev/

Does IBM DevOps Deploy correspond to the SLSA standards?   In short, I believe the answer to the question is “Yes, IBM DevOps Deploy does correspond to the SLSA standards.”   Let me try to prove this to you in the next sections of this blog post.

How IBM DevOps Deploy supports SLSA commitments

IBM DevOps Deploy supports SLSA commitments in the chain from a distribution perspective.   I will cover four points that help to prove this. 

Codestation

First, IBM DevOps Deploy has a built-in version repository that is called “codestation”.   This codestation repository cannot be tampered with and each deployable version that is created cannot be modified.

Codestation is IBM DevOps Deploy built-in version repository for the application artifacts that you will want to deploy.    The artifacts for deployment are referred to as component versions.   Here is an example of component versions for an App Connect Enterprise (ACE) component:

NOTE: IBM DevOps Deploy can integrate seamlessly with definitive asset repositories like JFrog Artifactory or Sonatype Nexus if a client desires to use this for storage of their artifacts.

Traceability back to the build

Second, each deployable version has a version label that is typically the “build tag” from a best practice perspective.   The build system creates the immutable artifact and then pushes the artifact to IBM DevOps Deploy’s version repository called “codestation” as discussed above.  

Here is an example of a build from Jenkins.  Notice the build tag of “3.0.112” as shown below:

The last step of the build process pushes the deployable artifact that was built to IBM DevOps Deploy.    You can make a REST API call or use a CLI command to perform this step.    Here is the result which shows the new component version in IBM DevOps Deploy:

Notice the new component version in IBM DevOps Deploy uses the same build tag version label.   When you click on 3.0.112, you will see the deployable artifact as shown below:

This artifact is immutable and cannot be modified.   This is an example of a broker archive that is deployed to an App Connect Enterprise (ACE) integration server.   You can add a version link which can provide a linkage back to the build, to the git commit, and to security scan results as an example which provides excellent trail of audit for SLSA commitments.

Statuses

Third, IBM DevOps Deploy has a concept of adding a “status” to a component version.   This helps you to know which versions have gone through all your testing processes to ensure the safety and quality of the version that you are deploying.   These statuses provide documentation of quality checks that were performed in each step of the software delivery lifecycle.   For example, if your system tests passed with a component version you have deployed in UAT, you can add a “System Tests Passed” status.

In the screenshot below, you see the statuses that are associated with a component version (Unit Tests Passed, SAST Passed, Functional Tests Passed):

Further, notice the version links above.   This provides excellent traceability back to your build (see the Jenkins link) as well as the results of Unit Tests, SAST scan results, and more.   With IBM DevOps Deploy, you can have tests run automatically following a deployment and then add the status for you programmatically when the tests complete along with a version link as shown above.

The status labels are customizable to meet your needs and can be configured in the Settings area of the IBM DevOps Deploy web console.

Gates

        Fourth, you can specify gates for your applications to ensure that the entry criteria is met before a component version can be deployed to a target   environment.    Gates help to ensure that good quality code progresses through your pipeline toward the PROD environment.    It helps to ensure that all the proper steps are followed before a deployment can take place.   Many times, gates are helpful to prove to auditors that you are following all the documented processes.

       Here is an example of gates that are configured for an application.   The statuses mentioned above are used as the gate or entry criteria for a deployment to a target environment.

The gates above are an excellent governance feature built-in to IBM DevOps Deploy. 

Finally, you can add “approval” requirements for certain environments and we have a built-in mechanism that provides this feature or we can integrate with external systems that provide the approval feature like Jira, ServiceNow, etc.

What about the Deployment?

I wanted to cover a few additional points where IBM DevOps Deploy supports the SLSA standards.   The following points will be covered:

• File integrity at time of deployment
• No tampering of the process
• Ensuring only certain roles can deploy to certain target environments

File integrity

The download artifact step in a component process will verify the files that are downloaded for deployment match what is in the codestation repository.   It will perform a full verification step to ensure the files being deployed are not tampered with and match the hash found in the codestation repository.

Here is an example of our 'Download Artifacts' step which downloads the files for deployment from our built-in codestation respository:

Notice the 'Full Verification' checkbox above.   When selected, hashes will be computed on each file in the destination artifact set to determine whether network transfer is necessary.   Otherwise, files will be compared by date modified and size.   The 'Verify File Integrity' checkbox, when selected, will verify the downloaded files match their hash.

No tampering of processes

Second, to ensure that someone doesn’t modify steps or inject steps into a process to try and hijack a deployment, we leverage team-based security so that you can make sure processes are “read-only” and cannot be edited by others.  

Our team-based security model allows you to create roles.   Each role will be configured with certain permissions.   For example, a “Developer” role can be configured so that he or she can see the deployment processes, however, they cannot edit or modify them.

Here is an example of a developer named “Dan” who has a read-only view of a component process:

Notice there is not a “save” button and there is no way to delete steps or add new steps.   The step palette is not even visible to them which is normally on the left-hand side of the screen.

Deployment to certain environments

Further, you can enforce which roles can deploy to different environments in your pipeline.   For example, a “Developer” role can be setup so that a developer can deploy to DEV but not to QA, UAT, or PROD.   The following screen shot illustrates this for a user named Dan who is a developer:

Notice that Dan can only deploy to the "DEV" environment.   Notice that the 'Request Process' button is not enabled for QA or PROD.

Summary

As you can see from the examples above, IBM DevOps Deploy will seamlessly work in an environment where SLSA standards are important to an organization.   It helps to ensure good quality code will ultimately be deployed to your different target environments while leveraging governance features and excellent team-based security.    These features help IBM DevOps Deploy to safeguard artifact integrity across the software supply chain.