software supply chain security

23 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

Ephemeral, isolated builds

Reuse and sharing of build environments may allow cache poisoning or malicious code injection. Builds should be performed in isolated, temporary ('ephemeral') environments using technologies such as VMs or containers, with environments immediately destroyed afterward.

SSC definition by NIST

According to NIST, an entity's Software Supply Chain (SSC) is defined as 'a collection of steps that create, transform, and assess the quality and policy conformance of software artifacts.'

Four categories of SSC threats

SSC threats are grouped into four categories: (1) Source code threats - violating integrity of source code through VCS exploits, malicious code introduction, or building from unauthorized branches; (2) Build environment threats - modifying artifacts through cache poisoning or compromising privileged accounts; (3) Dependency related threats - consuming vulnerable or compromised direct and transitive dependencies; (4) Deployment and runtime threats - exploiting deployment process or runtime environment through compromised CI/CD accounts or misconfigurations.

Implement Strong Access Control for SSC

Best practices for access control in SSC include: adhering to least privileges and separation of duties, enforcing MFA, rotating credentials, and ensuring credentials are never stored or transmitted in clear text or committed to source control.

Security automation in SSC

Automation of security tasks such as scanning, monitoring, and testing is critical for complex SSCs. Tools supporting automation include SAST, DAST, SCA, and container image scanners. These automation tools themselves must be maintained, secured, and configured correctly. Automation is one component of an overall SSC security program and cannot identify all vulnerabilities.

Peer code reviews for source code security

Manual code reviews are a low-cost technique for reducing SSC risk. Reviews should be performed by peers with experience in the technology and secure coding processes before code is merged into source control. Reviews should examine both unintentional security flaws and intentional malicious code. Results should be documented.

Secure VCS configuration

VCS security relies on strong access control and logging/monitoring plus VCS-specific security features such as protected branches and merge policies in git. Tools like Legitify can detect misconfigurations in GitHub and GitLab. Secrets should never be committed to VCS.

Secure development platform practices

Development systems should have endpoint security software installed and threat assessments performed. Only trusted, well-vetted software should be used including IDEs, plugins, and extensions. Development tools should be included in the organization's system inventory.

Assess suppliers before incorporating components

Before incorporating third-party services, products, or software components into the SSC, vendors and offerings must be thoroughly assessed for security. Evaluation should consider component maturity, security history, vendor's response to vulnerabilities, and third-party certifications such as FedRAMP, CSA, ISO/IEC 27001, ISO/IEC 15408, or ISO/IEC 27034.

Open source project assessment criteria

When evaluating open-source projects, assess: active maintenance status, popularity and community recognition, project maturity, whether it is a release version (not alpha/beta), sufficient number of maintainers relative to complexity, dependency update practices, test coverage including security-relevant tests, documentation including secure usage guidance, established vulnerability reporting and timely response process, and license consistency with intended usage.

Understand and monitor software dependencies

Dependencies must be carefully selected and monitored throughout the SDLC. Use SBOMs (Software Bill of Materials) to gain insight into consumed dependencies, with both production and consumption automated as part of CI/CD. Monitor dependencies for known vulnerabilities using tools like OWASP Dependency Check or retire.js. Monitor sources like NVD, OSVDB, or CISA KEV catalog for vulnerabilities.

SAST for OSS components

SAST tools can be used to detect potential security issues in open-source components within the SSC. SAST results may contain false positives and false negatives, so results must be manually verified and not accepted as comprehensive. Limitations must be understood but tools can prove useful when analyzing OSS code.

Lockfile and version pinning

To reduce likelihood of compromised or vulnerable versions being pulled into an application, limit dependencies to specific versions that have been previously verified as legitimate and secure. This is commonly accomplished using lockfiles such as package-lock.json used by npm.

Inventory build tools

An inventory of all build tools including versions and plugins should be automatically collected and maintained. Vulnerability databases, vendor security advisories, and other sources should be monitored for vulnerabilities related to identified build tools.

Harden build tools and infrastructure

Build tools require hardening to mitigate compromise risk. Techniques include: ensuring build tools are in appropriately segregated networks, using DLP and other tools to detect and prevent exfiltration, disabling/removing unused services, and using version control systems to manage and store pipeline configurations.

Enforce code signing

Software consumers should only accept digitally signed components and validate signatures before utilization to ensure authenticity and that the component has not been tampered with. Organizations performing code signing must thoroughly harden the code signing infrastructure to prevent compromise.

Use private artifact repository

Using a private artifact repository increases control over artifacts used in the SSC. Artifacts should be reviewed before admission to the repository and usage must not be bypassed. Private repositories increase maintenance and reduce agility but are important for sensitive or critical applications.

Version control for build scripts and config

CI/CD pipeline configuration and scripts should be stored in version control systems. This allows incorporation of reviews, merge rules, and other controls into the config update process. VCS use also increases visibility into changes and enables detection of malicious or benign modifications.

Provenance verification per SLSA 1.0

Provenance, defined by SLSA 1.0 as 'verifiable information about software artifacts describing where, when and how something was produced,' is important for ensuring components come from trusted sources and have not been tampered with. Provenance should be generated by the build platform (not local systems), be very difficult to forge, and contain all details to link results back to the builder. SLSA 1.0 compliant provenance can be generated using builders such as FRSCA or Github Actions and verified using SLSA Verifier.

Limit user-controllable build parameters

User-controllable parameters passed to build processes increase flexibility but also increase risk. If parameters can be modified by users to alter build behavior, attackers with sufficient permission can compromise the build process. Efforts should be made to minimize or eliminate user-controllable build parameters.

Scan final build binary

After the build process completes, binary composition analysis should be performed to detect exposed secrets, unauthorized components or content, and verify integrity. This task should be performed by both suppliers and consumers.

Monitor deployed software for vulnerabilities

SSC security extends beyond deployment; deployed software must be monitored and maintained to reduce risk. A wholistic approach is needed, monitoring code dependencies, container images, web servers, operating system components, and other system components. Accurate and up-to-date inventory of components is critical. Insecure configuration changes must be monitored and acted upon.

Real-world SSC compromise examples

The 2020 SolarWinds and 2021 Codecov incidents are examples of SSC compromises that propagated across many downstream entities due to the consumer-supplier relationship inherent in SSCs.

Give your agent this brain