A master plan to secure software development

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

A new approach is needed to secure the software development pipeline. In addition, 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 being applied.

A new model of pipeline security focuses on a flexible set of controls that secure the software creation pipeline by ensuring that authentication and authorization are properly handled, that the integrity of software artifacts is tested at the appropriate stages, and that controls are placed on third party and open source solutions built into the software. The result: software innovation and delivery with lower risk of supply chain tampering and reduced attacks during development.

A pragmatic design philosophy

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

  • Lesser privilege: Grant only the access and permissions necessary to complete a job, and no more.
  • Immutability: Artifacts and infrastructure are not changed after deployment in an environment. If a change is required, it is made in the image or script in the development environment, and then promoted to higher environments.
  • All as 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 it’s infrastructure or business code, are version controlled.

Control plane for software development pipelines

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

Control one: limit administrative access to CI / CD tools. Make sure that only authorized people can make administrative changes to the CI / CD system, preventing unauthorized changes to pipeline definitions.

Check 2: 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 code base.

Check three: Automation access keys automatically expire. By ensuring that access keys used by automation periodically expire, 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 on a least privileged access principle.

Check Five: Only dependencies from trusted registers can be used. By configuring the dependency manager to only allow connections to an allowed list of registries, attacks can be blunted by preventing malicious packages in public registries from entering the pipeline.

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

Check Seven: Artifacts are stored in a repository during development, preparation, and production. This control makes it possible to reinforce the immutability of the artefacts so that they can be compared in the development, transfer and production repositories.

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

New Check: Pull requests require a merge of two reviewers (including a default reviewer) and a successful build. In addition to supporting good coding practices, this control also helps ensure that no commitments are made without competent human oversight.

Check 10: Artifacts from higher repositories are signed. Requiring artifacts to be signed into a repository throughout the process ensures visibility and traceability of everything that is deployed in production.

Check 11: Available container images do not have high or critical vulnerabilities. Just as applications should be tested for vulnerabilities before they are put into production, so do the container images in which they are packaged for deployment. Container images can have open source vulnerabilities if they contain open source software.

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

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

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

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

We believe this model provides engineering teams with an actionable architecture that security teams can support and support. By adopting these standards, engineering teams are promised guaranteed software delivery with lower risk of supply chain tampering, reduction of attacks during development, and manipulation during preparation and production. .

Here is what it looks like:

plan

To learn more about the suggested plan, read our GitHub publication about the project. Our goal is to prioritize speed and agility in software development while incorporating a security-focused mindset.


Source link

Gordon K. Morehouse