A plan to secure software development

0

Software development has changed dramatically in recent years as technologies such as DevOps, application containers, and cloud native transform the way software is created and distributed. Unfortunately, attackers have been paying close attention to these changes and revamping their attack strategies to take advantage of the relatively weak security controls in software development and build environments. Attackers recognize that security teams focus more on infrastructure protection and less on software development and supply chains. This is how damaging attacks like SolarWinds happen – and attackers are likely to strike again for even more successful results.

A new approach is needed to secure the software development pipeline. Moreover, this approach must be implemented by the engineers who develop the software, and not by the information security teams. Engineering teams should be responsible for design and implementation while giving security teams visibility and assurance that controls are operational and policies are enforced.

A new plan for securing the pipeline centers on a flexible set of controls that secure the software development pipeline by ensuring that authentication and authorization are properly managed, the integrity of software artifacts are tested at appropriate stages, and that controls are placed on third parties. and open source solutions built into the software. The result: software innovation and delivery with lower risk of supply chain tampering and fewer attacks during development.

A pragmatic design philosophy

This modern software security plan is based on the following design philosophy:

  • Least Privilege: Grant only the access and permissions needed to complete a task, and nothing more.
  • Immutability: Artifacts and infrastructure are not changed after deployment to an environment. If a change is required, it is made in the image or script in the development environment and then promoted through higher environments.
  • Everything in code: Infrastructure, security policies, and other parts of the pipeline are also implemented as code and subject to the same controls as software artifacts.
  • Traceability: All changes, whether to infrastructure or business code, are version controlled.

Control plane for software development pipelines

The foundation of this software security plan revolves around a set of 15 controls designed for modern development pipelines where developers, pipelines, and execution can occur anywhere in the world.

Check one: Restrict administrative access to CI/CD tools. Ensure that only authorized individuals can make administrative changes to the CI/CD system, preventing unauthorized changes to pipeline definitions.

Check two: Only accept commits signed with a developer GPG key. Unsigned code commits are difficult, if not impossible, to trace and pose a risk to the integrity of the codebase.

Check three: Automation access keys expire automatically. By ensuring that access keys used by automation expire periodically, developers create a shorter attack window when keys are compromised.

Check four: Reduce access to read-only automation. CI systems should have read-only access to source code repositories based on the principle of least-privilege access.

Fifth check: Only trust registry dependencies can be used. By configuring the dependency manager to only allow connections to an allowed list of registries, attacks can be mitigated by preventing malicious packages in public registries from entering the pipeline.

Check six: Any critical or high-severity vulnerability halts the build. Supply chain attacks can introduce code with vulnerabilities into the software pipeline. Static Application Security Testing (SAST) helps identify serious security issues, including poor cryptographic practices, hard-coded credentials, and injection vulnerabilities.

Check Seven: Artifacts are stored in a repository during development, staging, and production. This check helps enforce the immutability of artifacts so they can be compared across development, staging, and production repositories.

Check eight: Validate the artifact summary. Before an artifact is deployed to an environment, its summary must be validated against the artifact in the repository to ensure that it has not been compromised.

Check nine: Pull requests require two reviewers (including a default reviewer) and a successful version to be merged. In addition to supporting good coding practices, this control also helps ensure that no engagement occurs without competent human oversight.

Check 10: Artifacts in top repositories are signed. Requiring artifacts to be signed in a repository throughout the process ensures visibility and traceability of anything deployed to production.

Check 11: Available container images have no high or critical vulnerabilities. Just as applications should be tested for vulnerabilities before being released into production, so too should the container images they are packaged in for deployment. Container images may have open source vulnerabilities if they contain open source software.

Check 12: Validate artifact signatures and summaries. Validating the artifact’s signature against the digest ensures that the artifact has not been tampered with in the repository and that the artifact being deployed is the same as the one that was tested.

Check 13: Analyze images deployed to production. This ensures that due diligence has been followed for all software in production.

Check 14: Validate Kubernetes resource manifests. If resource manifests are tampered with, they could be tricked into deploying a container of the attacker’s choosing.

Check 15: Ensure that build environments are ephemeral and immutable. Build environments should be defined in code with automated build and teardown and a new environment created for each build. Build hosts should not be accessible using interactive connections.

We believe this blueprint provides engineering teams with an actionable architecture that security teams can rally behind and take ownership of. By adopting these standards, engineering teams are promised assured software delivery with lower risk of supply chain tampering, reduced attacks during development, and manipulation in staging and production. .

Here’s what it looks like:

To learn more about the suggested plan, read our GitHub post about the project. Our goal is to prioritize speed and agility for software development while incorporating an always-on security mindset.

Share.

Comments are closed.