Integrating SSC Security into DevSecOps with NIST SP 800-204D

Stop me if you heard this, but Software Supply Chain (SSC) is a critical concern in #cybersecurity. All those libraries, components, SaaS, and third parties we use to build products come with risk. With the #nist publication SP 800-204D on integrating SSC security within #devsecops, we're reminded of this importance. In SSC, every activity significantly impacts the final product's security. This leaves organizations attempting to ensure the integrity of each step, from code writing to application delivery and containerization.

From the attacker’s perspective, supply chain attacks allow them to exploit legitimate, less secure channels to enter highly regulated environments and cause widespread damage quickly due to the interconnected nature of supply chains. The attacks leverage the inherent trust in these interconnection channels for rapid dissemination, making them particularly effective for achieving malicious objectives with potentially devastating impacts. A “force multiplier” if you will.

Well start with how the NIST Special Publication defines the basic compromise paths an attacker can take:

• Subverting, removing, or introducing a step within the SSC to maliciously modify or sabotage the resulting software product.
• Stealing credentials from the build system to mint and sign unauthorized malicious software.
• Causing naming collisions.

The worse part? Once inside the SSC, the attacker can target assets like source code, credentials, and sensitive data like PII, PHI, IP, and cryptographic materials. Development environments, rich in these assets, are critical points which make juicy targets. Organizations must identify these assets and secure them with controls like access restrictions, multi-factor authentication, encryption, and data loss prevention strategies to prevent unauthorized access. But there is more, much more, in the NIST publication to help develop these controls. First, we have to talk a bit about the exploitation by attackers.

Exploiting the SSC

So how does an attacker take advantage of an insecure SSC? As described in the NIST publication, an array of cybersecurity threats exist that can target various stages of the software development lifecycle (SDLC) within the organization. These threats include the injection of malicious code or dependencies into software projects, unauthorized access through stolen credentials, and the manipulation of code repositories to compromise sensitive data. Attackers leverage techniques such as forking and submitting pull requests to introduce vulnerabilities discreetly. This can be seen clearly when we look at opensource projects that allow for public contributions where there might be minimal oversight. The goal of these exploits is to undermine the integrity and security of software systems and deliver that force multiplier by compromising once with a large impact.

Securing the SDLC

I hope you are sitting down when you read this, but…SBOMs are not the answer. They are certainly a part of it, so don’t throw them out just yet, but they fall short in providing detailed vulnerability or defect information. This limitation means SBOMs alone are not enough for comprehensive vulnerability management, as they primarily offer just a component list for further analysis.

You may be sensing a theme here, but there is not a single tool or process to support security in the SSC. However, creating a secure SDLC will reduce the likelihood of security incidents stemming from an insecure SSC. These measures are vital for ensuring the confidentiality, integrity, and availability of the supply chains by assessing security risks and implementing appropriate defensive measures throughout the lifecycle.

Key measures in the SDLC included in the NIST publication are:

• Regularly applying patches and updates to software and systems to address known vulnerabilities and enhance security.
• Capturing and managing dependencies of artifacts in a central repository to ensure they are up to date and free from vulnerabilities.
• Implementing robust authentication mechanisms and granular authorization controls to ensure only authorized users have access to sensitive resources and functionalities.
• Implementing encryption, access controls, and data loss prevention measures to safeguard sensitive data throughout the SDLC.
• Implementing logging, monitoring, and auditing mechanisms to detect and respond to security incidents and track changes to software artifacts and systems.
• Ensuring compliance with relevant security standards and regulations, such as OWASP Top Ten, SP 800-53, HIPAA, and PCI DSS (industry dependent).
• Establish trusted sources for OSS and verify digital signatures to ensure software authenticity. Even better, use internal repositories if possible.
• Conduct regular vulnerability scans and dependency checks and audit the CI/CD processes.

Note: If you need help in developing or maturing an application security program…there is a phenomenal book written by Derek Fisher called the “Application Security Program Handbook” that walks through this and more!

So, we have SBOMs, a secure SDLC, and I’d be remiss if I didn’t call out the controls highlighted in the NIST publication related to source control management (SCMs) as well. These tools are used to push/pull code regularly by developers via their development environment within defined SDLC processes. Access policies vary between open-source (minimal restrictions) and proprietary projects (strict access rules).

SSC, DevSecOps, and the CI/CD

How does all this play into the CI/CD pipelines and DevSecOps?

There is a lot to unpack in the NIST publication, so I’ll stick to the high-level points for brevity’s sake. First a bit of a refresher on DevSecOps and CI/CD.

• DevSecOps involves a series of stages, including building, packaging, testing, and deploying code. Where the “Sec” part comes in is the emphasizes on the early and continuous integration of security measures throughout the application lifecycle, promoting faster, more secure software delivery.
• The CI/CD represents a cornerstone of modern software development technology, where DevSecOps is more of a methodology. In CI/CD, source code is housed within an SCM. The build process compiles source code from these SCMs and produces build artifacts. These artifacts undergo testing and are further packaged into something that can be run in an environment (example: container image, jar, exe). The final packages are stored in dedicated repositories for scanning prior to deployment in testing or production environments. This series of stages and tasks, from artifact creation to deployment, encapsulates what are CI/CD pipelines.

Good news, the NIST publication provides detailed strategies for defending CI/CD pipelines, emphasizing measures like strengthening execution environments, establishing clear roles and permissions, leveraging automation tools, and implementing security guidelines. Other specific recommendations are:

• Strengthening the execution environment (e.g., VMs or pods) minimizes the attack surface, safeguarding the pipeline from potential threats.
• Clearly establishing roles for individuals managing the CI/CD pipelines, such as application updaters, package managers, and deployment specialists, ensures a structured and secure pipeline operation.
• Implementing detailed permissions for tasks, including code generation and commits, build and package generation, and artifact management within repositories, enhances security by restricting access to necessary actions only.
• Leveraging automation tools streamlines the CI/CD pipeline, from code checkout to testing phases, including Static Application Security Testing (SAST), Dynamic Application Security Testing (DAST), and Software Composition Analysis (SCA). Higher-level driver tools orchestrate these functions, operating with a higher trust level than individual steps.
• Establishing security guidelines for different pipeline activities, from application code development to deployment, including infrastructure as code and policy/configuration code, fortifies the pipeline against vulnerabilities.

The one key takeaway is that if you are not securing the factory that produces your product, you have less confidence in the product being produced.

Where does that leave us?

Every aspect of SSC, from code inception to application deployment, bears weight on the final software product's security which necessitates robust measures at each step. The NIST publication certainly provides a well-defined set of guidance and implementation steps for organizations looking to secure their products. To that end organizations should focus on these key takeaways:

• Emphasize policy enforcement and evidence generation throughout the build process.
• Include attestations for environment, process, materials, and artifacts to ensure integrity and authenticity.
• Implement checks on code integrity, sandboxing CI pipelines, and integrating external security tools.
• Prioritize protection against attacks on evidence generation to ensure the trustworthiness of downloaded files.
• Incorporate measures to safeguard signing operations and mitigate key compromise risks.
• Mandate the use of SAST, DAST, and SCA tools to assess code quality and dependencies, with a focus on preventing secrets from being included in committed code.
• Evaluate code commits for policy adherence and preventing unauthorized pushes.
• Conduct reviews before merging pull requests to identify and address vulnerable versions.
• Ensure artifacts originate from secure build environments to maintain integrity.

While there's no one-size-fits-all solution for SSC security, adopting a holistic approach, as outlined in NIST SP 800-204D, offers a robust framework to safeguard against evolving cyber threats across the software supply chain.