Secure software supply chain lifecycle logical architecture

The logical architecture for the secure software supply chain lifecycle is illustrated in the logical architecture diagram below.

Lifecycle and capabilities - logical diagram

Development security and integrity

Within the develop phase, developers must be supported to ensure the security and integrity of all code, binaries, and configuration that is expected to be included in the software release.

Develop phase capabilities - logical diagram

The development environment encompasses all the tools that the developer uses to write, build, and test code. Examples include VS Code, Devcontainers and/or GitHub Codespaces. The development environment uses a code repository to store the code that's written. Additional components, such as libraries, frameworks, and container base images, are retrieved from a component registry.

Repeatable and deterministic builds are an important aspect of a secure software supply chain. These ensure that the contents that make up a software release are well known, and any attempts to tamper with the artifacts can be detected. The development ecosystem used within the develop phase must capture a record of all its dependencies. Examples of this component inventory include application package managers (npm, NuGet, go.mod), OS package managers (winget, apt get), and container manifests (Dockerfile). Version pinning of components from the component registry is encouraged to ensure that builds remain deterministic.

To improve integrity and security, developers use the Digital signing capability to ensure that all code commits are cryptographically signed in their trusted environment. Signing commits contributes to the trust chain for the code. Signing keys are managed via a certificate store.

In addition, developers use the Artifact scanning capability to lookup vulnerabilities for the current version of each dependent component. For example, developers might learn that the current version of a component has an unacceptable vulnerability, and they can immediately mitigate that risk by switching to a version without the vulnerability.

The Policy-as-code capability is used to enforce policies available via a policy store. Example policies might include:

  • No code can be committed without signing.
  • No code with a non-zero number of critical severity vulnerabilities can be committed.
  • Component versions must be pinned.

The Building a knowledge graph capability provides deeper insights into the software supply chain to ensure that risks can be identified and mitigated in new code releases.

Build processes security and integrity

Within the build phase, the processes that create a software release must be supported to ensure the security and integrity of the software release.

Build phase capabilities - logical diagram

The build agent retrieves code from a code repository and pulls down dependencies from their associated component registries. Examples of component registries include the registries for package managers and container registries for container base images. Security and compliance teams may deny access to public component registries and enforce the use of internal/private registries instead. This is to ensure integrity across the entire software supply chain used to build the software release.

The build agent uses the code and component to build a software release. In containerized workloads, the release artifact is typically a container image.

Building a knowledge graph is used to store traceability details about the software build process and subsequent release details.

Build-time policies are enforced by Policy-as-code) through an initial policy gate to ensure that the software release has been built in a secure and compliant manner. An example is a policy that enforces pinning dependency versions for all components.

Security artifacts are built to improve the integrity and security of the software release:

  • The Software composition analysis capability is used to build a Software Bill of Materials (SBOM) which is a collection of all the components used to build the software release. This can also include information like version and license.
  • The Attestations capability is used to create any required attestations relevant to the building of the software release.
  • The Artifact scanning capability is used to produce a collection of vulnerabilities for all the associated components.
  • All the security artifacts (SBOM, Attestations, Vulnerability scans) produced are cryptographically signed using the Digital signatures capability to ensure that any tampering with these artifacts can be detected.
  • Signing keys are managed via a certificate store.
  • The Building a knowledge graph is used to associate each security artifact with the software release.

Build-time policies are enforced by Policy-as-code through a second policy gate, using the additional information from the security artifacts to ensure that the software release is still secure and compliant. An example of policies here could include no release without signed security artifacts, no release if any critical vulnerabilities are detected in components, no release if any components use non-compliant licensing.

The software release is published to an artifact repository, such as a container registry. The software release is associated with additional release details with the Building a knowledge graph. Examples of additional release details include service (GitHub, Azure DevOps), repository (repo url), and release commit (git commit). Some implementations may bundle the security artifacts with the software release in the artifact repository, treating the whole as a "package." Other implementations may rely on the security artifacts being referenced via the knowledge graph, with the artifact repository simply storing the software release.

Deployment integrity verification and security risk checking

Within the deploy phase, a workload that references the software release is deployed to a Kubernetes cluster. Policy enforcement verifies the integrity and checks the security risks for the software release before allowing the deployment to be scheduled.

Deploy phase capabilities - logical diagram

The workload may be provisioned via either push-based (pipelines, control planes) or pull-based (GitOps) deployments, since the policy enforcement runs within the Kubernetes control plane boundary.

Kubernetes enforces a policy gate with policies from a policy store (see Policy-as-code). Policy enforcement verifies component signatures (see Digital signatures) on container images and security artifacts. Policy enforcement may also use information from the artifact repository and/or Building a knowledge graph to enforce rules around integrity and security of the workload being deployed.

Kubernetes pulls the container images required by the workload from the artifact repository, and then schedules them to run on a node. A mechanism that can be local to the Kubernetes cluster or part of the knowledge graph system uses the Building a knowledge graph functionality to associate the deployed software release with operational details. An example of the relationships stored in the knowledge graph includes - "which cluster, in which region, is running the software release, which is composed of a workload definition and associated container images".

Operate phase verification

Within the operate phase, a regular policy audit process ensures that any changes in the integrity and security of deployed software releases are noted and acted upon.

Operate phase capabilities - logical diagram

Security artifacts like SBOMs and signatures are static and don't change over time. These artifacts ensure that the integrity of a software release can be verified. Artifacts like vulnerability scans are more dynamic and the risks they represent may change over time. For example, new vulnerabilities may be detected in components that were considered safe when first built or used in a software release.

Since new vulnerabilities are constantly emerging, it's critical to regularly monitor existing software releases to identify components for which new vulnerabilities have been identified. This is done with a scheduled job and (Artifact scanning](../../../Capabilities/security/scanning.md) that scans software releases and audits their Policy-as-code capabilities to identify new security risks. New risks are associated with the software release and the identified components within the Building a knowledge graph capabilities. These new risk associations in the knowledge graph can be used by the security team to proactively mitigate security risks, or by the deployment policy gates to automatically ensure that no new deployments of the software release will be accepted by the Kubernetes cluster.

The Kubernetes cluster may also use the Building a knowledge graph capability to associate runtime violations with the cluster, deployment, and software release. An example is a security component in Kubernetes identifying an attempt to escalate access privileges in a workload. This could indicate a security risk due to misconfiguration of the workload, or a vulnerability in the container image used by the workload.

Knowledge Graph observability risk identification/mitigation

Building a knowledge graph is used across all lifecycle phases to provide deep insights into the relationships between the software supply chain artifacts, and the systems and processes that touch them. This ensures traceability across the system and allows for a quick and efficient mechanism for identifying risks so that they can be mitigated.

For more information