Secure software supply chain: Deliver software to production quickly and securely

Implementing a secure software supply chain is integral to securing software development and accelerating your DevSecOps capabilities.

What is a secure software supply chain?

A secure software supply chain is the set of processes used to deliver your software to production—including all its dependencies—securely, reliably, and consistently with regular updates to source code and defined controls for platform governance.

A secure software supply chain provides confidence that your code and its dependencies are trustworthy, compliant, updated, and release ready, and ensures that regular scans are in place to detect, report, and eliminate vulnerabilities. With a defined set of policies enforced consistently across all systems in the chain, it prevents unauthorized access and prohibits unsigned packages to run.

---

Secure software supply chain best practices

To develop a secure software supply chain, you need a set of tools and practices that enable your organization to deliver software packages—both first- and third-party—from source code to production at a sustained high speed and quality relative to your accepted risk level.

VMware has identified five areas of focus for secure software development that will allow organizations to integrate security into agile software development and help to mitigate software supply chain attacks.

1. 1. Securing the application source code

   Within the software development lifecycle, the part of the supply chain that you have the most control over is the code you write. A secure supply chain doesn't matter if it’s shipping insecure code. By implementing strategies to ensure this code is secure, you can help mitigate supply chain attacks.

   Best practices

   • ◼ Provide developer enablement to support security readiness in production environments.
   • ◼ Use access control for code repos to deter unauthorized and unwanted code changes.
   • ◼ Utilize code linting/static code access, which can help catch common programmatic errors during development time before they have a chance to become production bugs that may be exploited.
   • ◼ Include peer code review to prevent both unintentional vulnerabilities introduced due to error and those that are intentionally and maliciously introduced by a bad actor.
   • ◼ Enforce secret management so that source code is free of sensitive credentials and configuration in order to prevent an attack should the code be leaked, reverse engineered, or otherwise made public.
   • ◼ Use Static App Security Testing (SAST), a type of software security testing, to scan source code and search for coding patterns that match known weak coding practices.
   • ◼ Employ Source Composition Analysis (SCA) to verify the third-party libraries, frameworks, and components used in the application.

   Outcomes

   • ◼ App developers are enabled to develop high-quality code by following security best practices.
   • ◼ All commits to the repo are trusted.
   • ◼ Source code is free of secrets or other sensitive environment data.
2. 2. App dependency management

   Few developers start from scratch when creating their builds. To save time and speed up development, they can use prebuilt code from open source and other catalogs. This means that software must take into account the pieces of prebuilt code integrated in the final build when checking for and patching vulnerabilities in the app in production.

   To ensure secure software design and development, your teams need to be able to clearly visualize their application dependencies. Regularly scanning to ensure all dependent libraries are patched and free of Common Vulnerabilities and Exposures (CVEs) will reduce the chances that a dependency will be exploited.

   Best practices

   • ◼ Incorporate dependency vulnerability scanning with regular scans to ensure all dependent libraries are patched and free of CVEs.
   • ◼ Patch vulnerable dependencies in a timely manner.
   • ◼ Use dependency pinning (lockfiles)—pinning dependencies to specific, verified versions—to help prevent cases where new vulnerabilities are introduced by inadvertently updating a dependency.
   • ◼ Consider using dependencies acquired from well-known and reputable sources that are used by a large number of developers, which can be less likely to be compromised than those from less trustworthy locations.
   • ◼ Know exactly which dependencies are in use. Modern applications often consist of dozens or more dependencies, creating an attack vector where vulnerabilities are introduced deep in the dependency hierarchy.
   • ◼ Reason about when to take on a new dependency. In some cases, attack surface can be minimized by avoiding taking on large dependencies.
   • ◼ Evaluate updates to existing dependencies. Software vendors often distribute updates from a centralized server as part of routine maintenance. An attacker who is able to infiltrate the vendor's network can insert malware into what appears to be a regular product update.
   • ◼ Practice risk management.

   Outcomes

   • ◼ Developers can confidently validate provenance for third-party and internal dependencies.
   • ◼ App teams can fully visualize their application’s software bill of materials.
   • ◼ Stakeholders can quickly identify which applications may be vulnerable to CVEs.
   • ◼ Ensures low-friction patching of application dependency vulnerabilities.
3. 3. Secure CI/CD systems

   Governance is an important part of controlling your continuous integration and continuous delivery (CI/CD) pipeline. Making sure permissions for system use are in place and correctly configured can help to secure your software supply chain. This includes least required privileges.

   Best practices

   • ◼ Implement access control for CI/CD pipelines and prevent bypass in pipelines by eliminating side doors.
   • ◼ Use system accounts with the least required privileges to run jobs, tasks, and scripts in automation pipelines.
   • ◼ Use pull-based deployments instead of push-based. When using push-based deployments, you have to expose credentials outside of the target system. In pull-based deployment scenarios, credentials of the target system are not being exposed, but controllers sync state changes from Git repos (GitOps) or image registries.
   • ◼ Use credential management for CI/CD pipelines and ensure your deployment tooling requires credentials to your most sensitive environments.
   • ◼ Generate and store build logs and audit trails.

   Outcomes

   • ◼ Developers can confidently validate provenance for third-party and internal dependencies.
   • ◼ App teams can fully visualize their application’s software bill of materials.
   • ◼ Stakeholders can quickly identify which applications may be vulnerable to CVEs.
   • ◼ Low friction patching of application dependency vulnerabilities.
4. 4. Secure image build and registry

   The goal when making container images more secure is to reduce the number of high CVEs in the image registry and reduce the target time required to fix CVEs. We can achieve this by ensuring base images are trusted and signed and that control policies are enforced for the image repository.

   Best practices

   • ◼ Implement control/access policies for image repos. All image references in use should have been authorized and validated by an automated CI process, making access outside of this minimal.
   • ◼ Utilize a small set of approved base images to reduce attack surface area. Ensure base images are signed and versionned. Trusted base images are determined, made available, and used for the build.
   • ◼ Store app images and/or artifacts in a secure place. Enforce control policies for image repositories and ensure images are signed when stored in a registry.
   • ◼ Update the vulnerability database and use it for regularly scheduled image vulnerability scanning.
   • ◼ Utilize a secure image build that is reproducible and produced using a known set of only trusted artifacts. Ensure introduction of backdoors during the build is difficult, and can be detected.
   • ◼ Trace artifacts that are promoted to production to ensure that the same artifacts used for testing are promoted to higher environments. Audit trails are available.
   • ◼ Utilize image tagging.
   • ◼ Validate attestations.

   Outcomes

   • ◼ Application images are signed to guarantee their integrity.
   • ◼ Images are stored in a secure registry.
   • ◼ Confidence in deployed artifacts.
   • ◼ Visibility of image vulnerabilities.
   • ◼ Operationalized image vulnerability remediation.
5. 5. Secure runtime

   Implementing zero-trust architectures and Security Information and Event Management (SIEM), along with advanced threat detection tools, creates a more secure environment for your applications and application development platform. Integrating observability into your platform operations will help you to monitor your runtime and understand how your apps are performing.

   Best practices

   • ◼ Security engineers should be able to detect attacks by correlating a number of events, possibly via a SIEM tool, and other threat detection tools that can identify certain events indicating that an attacker has gained access.
   • ◼ Use runtime vulnerability scanning to help you identify vulnerabilities in Kubernetes environments.
   • ◼ Implement secure networking to prevent attackers from gaining access to one network and then easily traversing to other trusted networks and environments. Securing data in transit through secure communications is essential to prevent an attacker from sniffing network traffic.
   • ◼ Use a secure multitenancy strategy. Empoy a namespace and cluster strategy for isolation, adding role-based access control.
   • ◼ Correctly configuring your development environment so you can avoid security breaches often caused by misconfigured infrastructure.
   • ◼ Use secrets management to ensure that secrets are securely distributed to apps and services that require them, and that these apps and services can only access the secrets they need in order to function. This helps reduce the attack surface and impact of a potential breach.
   • ◼ Implement secure environment access to ensure only authorized users have access to your environment. Multiple different security controls may be appropriate to make sure that this is the case. Unauthorized access should be detectable.
   • ◼ Utilize dynamic app security testing (“black box” testing) to find security vulnerabilities and weaknesses in a running application.
   • ◼ Prevent unsigned images from being run in a prod environment.
   • ◼ Reduce time to remediate security vulnerabilities in your supply chain.
   • ◼ Use consistent policy enforcement. Determine, apply, and test security policies, log auditing, compliance policies, and network policies.
     • Security and access policies are consistently enforced.
     • The system refuses to run any code that did not come from the secure software supply chain.
     • It's easy to make mistakes writing (rego) policies, so you should develop them with care and appropriate testing.
     • Test integrated policies to ensure no conflicts.

   Outcomes

   • ◼ Isolation of workloads is guaranteed so that neighboring workloads cannot impact, access, or interfere with them.
   • ◼ Communication between services over the network is safe and reliable.
   • ◼ Developers can quickly visualize application CVE.
   • ◼ Feature fresh, up-to-date, and secure workload hosting platform.

The importance of a secure software supply chain

The focus on software development has become acute in the past few years as supply chain attacks have become more prolific. Recently, the Executive Order on Improving the Nation’s Cybersecurity outlined supply chain security best practices for organizations. It seeks to address supply chain compromises in which attackers gained access to the development process and inserted malware into the source code. This malware was able to propagate downstream in published software and allowed attackers to steal information from the organizations running the application. The Executive Order creates an impetus for organizations in the United States to develop more secure software supply chains and avoid compromises that could disrupt critical infrastructure functions.

Understanding and mitigating vulnerabilities in your path to production helps to de-risk business investments, provides opportunities to deliver more secure software to end users at a rapid pace, and removes friction for developers deploying code. Tanzu offers solutions for secure tooling with operator-defined guardrails that developers will love to use. Tanzu Labs experts work with you to establish processes for your organization that provide greater collaboration between development and security teams. We’ll help you improve your DevSecOps practice with our proven solutions and get you started securing your application development process on a secure platform where you can build ideas that provide value to your business.