DevSecOps Pipeline From Scratch: The Security Baseline for a New Project
The minimum security controls to wire into your pipeline on day one, ordered so you catch real risks before you drown in noise.
Executive Brief
- A DevSecOps pipeline from scratch starts with six baseline controls added in a specific order: secrets scanning, static analysis (SAST), dependency scanning (SCA), container image scanning, SBOM generation and artefact signing.
- The order matters because adding dependency scanning before secrets scanning means hundreds of noisy CVE alerts hit a team that hasn't yet locked down the credentials committed in its first sprint.
- Secrets scanning with a pre-commit hook (Gitleaks or similar) is the single control that prevents the hardest category of incident to remediate: a leaked credential that's already been harvested.
- SBOM generation using CycloneDX or SPDX is becoming a regulatory requirement under the EU Cyber Resilience Act and is already expected by enterprise buyers running supply-chain due diligence.
- Build provenance (SLSA) and keyless signing (Sigstore/Cosign) give downstream consumers a verifiable chain from source commit to deployed artefact.
- The four questions that shape every architecture apply directly here: what has to be true before this ships (the gate); how we prove it was true six months later (the evidence); what undo costs (the rollback); what a test environment physically has to be (the harness).
Why Adding Security at the End Fails
Most teams plan to "add security later." The phrase comes up in sprint planning, in architecture reviews, in retrospectives after the first production incident. And every time, later means after the patterns are set, the dependencies are locked, and the credentials are baked into environment variables that nobody documented.
By the time a team bolts on a SAST scanner six months into a project, the backlog it generates is so large that the default response is to suppress findings. That's not a tooling problem. It's a sequencing problem.
The cost of remediating a vulnerability rises with each stage it passes through undetected. A secret committed in a feature branch costs a few minutes to rotate if caught by a pre-commit hook. The same secret, once pushed to a shared repository and picked up by a CI runner, now requires auditing every system that runner touched. If it reaches a container image published to a registry, the blast radius includes every environment that pulled that image.
The fix isn't a bigger security review at the end. It's six controls, added in the right order, starting on the first day of the project. Not on day ninety.
Baseline Controls: The Order That Keeps Noise Low
The table below lists the minimum controls for a DevSecOps pipeline from scratch, in the order you should add them. This sequence is deliberate: each control builds on the one before it, and adding them out of order creates alert fatigue before the team has built the muscle to respond.
| Order | Control | What it catches | Example tooling | When it runs |
|---|---|---|---|---|
| 1 | Secrets scanning | API keys, tokens, passwords, private keys committed to source | Gitleaks (pre-commit hook + CI) | Pre-commit and on every push |
| 2 | Static analysis (SAST) | Code-level vulnerabilities: injection, insecure deserialisation, hardcoded config | Semgrep, CodeQL | On every pull request |
| 3 | Dependency scanning (SCA) | Known CVEs in third-party libraries and transitive dependencies | Trivy, Grype | On every pull request and nightly |
| 4 | Container image scanning | OS-level vulnerabilities in base images, misconfigurations in Dockerfiles | Trivy | After image build, before registry push |
| 5 | SBOM generation | Complete inventory of every component in the shipped artefact | Syft (CycloneDX or SPDX format) | At build time, attached to release artefact |
| 6 | Artefact signing and provenance | Tampering between build and deploy; unverified origin | Sigstore/Cosign, SLSA provenance | After build, verified before deploy |
Why secrets scanning first? Because a leaked credential is the one category where speed of detection determines the outcome. A CVE in a dependency can sit in a backlog for a week while the team triages its severity. A leaked AWS access key will be harvested within minutes of being pushed to a public repository.
SAST comes second because the codebase is still small. Running Semgrep against a ten-file project produces a manageable set of findings. Running it against eighteen months of accumulated code produces noise that gets ignored.
Dependency and container scanning come next because they operate on inputs the team doesn't fully control (third-party packages, upstream base images). These scanners are noisier by nature, so waiting until the team has already built habits around secrets and SAST findings means the response workflow already exists.
SBOM generation and artefact signing are last not because they're least important, but because they require the rest of the pipeline to be stable. Generating an SBOM from a build that doesn't reproducibly produce the same artefact is busywork. Signing an artefact that wasn't scanned is signing a promise you haven't verified.
Reference Pipeline With Security Gates
A DevSecOps pipeline from scratch for a containerised application typically has five stages. The architecture below describes what happens at each stage and where the security controls from the previous section slot in.
Stage 1: Pre-commit (developer workstation)
Gitleaks runs as a Git pre-commit hook. If a secret is detected, the commit is blocked before it ever reaches the remote repository. This is the cheapest point of interception, and the only one where the secret genuinely never leaves the developer's machine.
Stage 2: Pull request checks (CI runner)
When a developer pushes a branch and opens a pull request, the CI runner executes three parallel checks: Gitleaks (again, as a backstop for developers who bypass the hook), Semgrep or CodeQL for static analysis, and Trivy or Grype for dependency scanning. Results are posted as pull request comments. Any critical or high finding blocks the merge.
Stage 3: Build and package (CI runner)
The application is compiled, tested and packaged into a container image. Syft generates an SBOM in CycloneDX format and attaches it to the build artefacts. Trivy scans the container image for OS-level CVEs. The image is tagged with the Git commit SHA.
Stage 4: Sign and publish (CI runner to registry)
Cosign signs the container image using keyless signing through Sigstore's public Fulcio and Rekor instances. SLSA provenance metadata is generated and attached. The signed image and its provenance attestation are pushed to the container registry.
Stage 5: Deploy gate (deployment pipeline)
Before the image is pulled into a staging or production environment, the deployment pipeline verifies the Cosign signature and checks the SLSA provenance attestation. If the signature is missing or the provenance doesn't match the expected build system, the deployment is rejected. Policy enforcement at this stage can be handled by tools like OPA, Conftest or Kyverno.
Secrets Management in CI
The worst category of security incident in a CI/CD pipeline is a committed credential. Not because the credential itself is hard to rotate, but because the window between commit and discovery determines how much damage is done, and that window is often measured in months, not minutes.
Two things need to happen. Secrets need to be kept out of the repository entirely, and the pipeline needs a way to inject them at runtime without storing them in CI environment variables where every job can read them.
Keeping secrets out of source
Gitleaks, configured as a pre-commit hook, scans staged files against a set of patterns (AWS keys, GCP service account JSON, private RSA keys, generic high-entropy strings). It's fast enough to run on every commit without developers noticing the delay.
The pre-commit hook alone isn't sufficient. Developers can skip hooks with --no-verify, and not every developer's machine will have the hook installed. Running Gitleaks again in the CI pipeline as a push-time check catches anything that slipped through.
For teams already using a monorepo or working across multiple repositories, a centralised Gitleaks configuration file avoids drift between repositories. Store it in a shared repository and pull it in as part of the CI setup step.
Runtime injection instead of stored variables
CI platforms let you store secrets as environment variables accessible to all pipeline jobs. That's convenient and dangerous. Any job in the pipeline can read every stored secret, and a compromised dependency running in a test step has access to production database credentials.
The alternative is vault-based injection. HashiCorp Vault, AWS Secrets Manager and similar tools issue short-lived credentials scoped to the specific pipeline step that needs them. A build step that compiles the application never sees the deployment credentials. A test step that runs unit tests never sees the signing key.
The tradeoff is complexity. Vault-based injection requires a secrets backend, an authentication method for the CI runner (typically OIDC federation), and per-step policies. For a small team starting a new project, scoped CI variables (where the platform supports scoping secrets to specific environments or jobs) are a pragmatic first step. Move to vault-based injection once the number of secrets or the number of pipeline consumers makes scoping unmanageable.
SBOMs, Signing and Build Provenance
An SBOM (Software Bill of Materials) is a machine-readable inventory of every component in a shipped artefact: libraries, frameworks, operating system packages, and their exact versions. Two formats dominate: CycloneDX and SPDX.
Why generate one? Two reasons. First, when a new CVE is disclosed, an SBOM lets you answer "are we affected?" in seconds instead of hours. Without one, someone has to grep lock files across every repository and hope the deployed version matches what's in source control. Second, regulators and enterprise buyers increasingly require SBOMs as a condition of procurement. The EU Cyber Resilience Act is one example. The Yocto SBOM guide on this site covers the embedded-specific considerations.
Syft is the most widely adopted open-source SBOM generator for container images. Point it at a built image, and it produces a CycloneDX or SPDX document that can be attached to the release metadata.
Artefact signing with Sigstore and Cosign
An SBOM says what's in the artefact. Signing says who built it and whether it's been tampered with since. Cosign, part of the Sigstore project, supports keyless signing: instead of managing a long-lived signing key, the CI pipeline authenticates through its OIDC identity provider (GitHub Actions, GitLab CI and most major CI platforms support this natively), and Sigstore issues a short-lived certificate tied to that identity. The signature is recorded in Rekor, Sigstore's public transparency log.
For teams running their own infrastructure, Sigstore components can be self-hosted. For most new projects, the public instance is the pragmatic starting point.
SLSA provenance
SLSA (Supply-chain Levels for Software Artifacts) is a framework from the Open Source Security Foundation that defines levels of build integrity. At its simplest, SLSA provenance is a signed attestation that records which source repository, commit and build system produced a given artefact. Consumers can verify this attestation before deploying.
The current SLSA specification defines build levels (L0 through L3) based on how much of the build process is controlled and auditable. For a new project, generating provenance metadata and attaching it to the signed artefact (SLSA Build L1 or L2, depending on the build platform) is the practical starting point. Reaching L3 requires a hardened build platform with isolated build environments, which is a later-stage investment.
Compliance and Regulatory Connection
The controls described in this article map directly to obligations in multiple regulatory frameworks. Rather than restating regulation-specific requirements here (see Audit-Ready CI/CD for Regulated Software for the full cross-regulation mapping), the connection points are:
The EU Cyber Resilience Act requires manufacturers of products with digital elements to maintain SBOMs and implement vulnerability handling processes. The SBOM generation and dependency scanning controls in this pipeline satisfy the technical implementation side of those obligations.
The NIST Secure Software Development Framework (NIST SP 800-218) provides a set of practices for secure software development, including requirements around build integrity and vulnerability detection that align with the baseline controls table above.
For teams operating under HIPAA technical safeguards, the secrets management and access control patterns described here contribute to the access control and audit requirements in the Security Rule.
No pipeline configuration alone satisfies a regulation. These controls produce the technical evidence that a compliance programme needs, but the programme itself (policies, risk assessments, incident response procedures) is a separate workstream.
Should You Build This or Bring in Help?
A DevSecOps pipeline from scratch is a concrete engineering project with a defined scope. The six controls in this article, wired into a working pipeline with signing, provenance and policy gates, represent a baseline that every new project should ship with.
The question is whether your team has both the expertise and the bandwidth to build it while also shipping the product the pipeline is supposed to protect.
The factors that make this harder than it looks on paper:
- Tool selection involves tradeoffs that aren't visible until you've run each scanner against a real codebase and tuned its rules. Semgrep and CodeQL solve similar problems differently, and the wrong choice for your language stack means either missed findings or excessive false positives.
- Keyless signing with Sigstore requires understanding OIDC federation between your CI platform and Fulcio. The documentation is good but assumes familiarity with X.509 and transparency logs.
- SBOM generation is only as useful as the process around it. Generating a CycloneDX document and never checking it against new CVE disclosures is compliance theatre.
- Policy gates (OPA, Conftest, Kyverno) need policies written in Rego or CEL. Someone on the team needs to learn a policy language, write tests for it, and maintain it as requirements change.
Take the Stonetusker readiness check to see where your current pipeline stands relative to these baseline controls. The check is free and doesn't require an email address.
Stonetusker's Secure Delivery practice builds exactly this kind of pipeline, fitted to your regulatory context and technology stack, within a fixed 90-day engagement. If your team knows what it wants to build but doesn't have the spare cycles to build the delivery infrastructure around it, book a 30-minute call to talk through the specifics.
- DevSecOps Pipeline
- Secrets Scanning
- SAST
- SCA
- SBOM
- Sigstore
- SLSA Provenance
- Container Security
- Supply Chain
Frequently Asked Questions
What is a DevSecOps pipeline?
A DevSecOps pipeline is a CI/CD pipeline with security controls built into every stage rather than applied as a separate review at the end. It automates secrets scanning, static analysis, dependency checking, container scanning, SBOM generation and artefact signing so that security findings surface alongside functional test results, in the same pull request workflow developers already use.
Which security tools should go into a CI/CD pipeline first?
Start with secrets scanning (Gitleaks or a similar tool configured as a pre-commit hook and a CI check). It catches the highest-impact class of vulnerability, leaked credentials, with almost no false positives. After that, add static analysis (Semgrep or CodeQL), then dependency scanning (Trivy or Grype), then container image scanning, and finally SBOM generation and artefact signing. The order is designed to minimise alert fatigue: each control is added only after the team has built response habits for the previous one.
What is an SBOM and why does a pipeline need one?
An SBOM (Software Bill of Materials) is a machine-readable list of every component, library and package included in a software artefact, along with their versions and licences. Pipelines need SBOMs for two reasons: they let you answer "are we affected?" within seconds when a new vulnerability is disclosed, and they satisfy the transparency requirements that regulators (such as the EU Cyber Resilience Act) and enterprise buyers increasingly demand. CycloneDX and SPDX are the two dominant formats.
How do you scan for secrets in a code repository?
The most practical approach is a two-layer setup. First, install Gitleaks as a Git pre-commit hook on every developer's machine, so secrets are caught before they leave the workstation. Second, run the same Gitleaks scan in the CI pipeline on every push, as a backstop for commits where the hook was bypassed. Gitleaks matches against patterns for common credential types (AWS keys, GCP service accounts, generic high-entropy strings) and can be extended with custom rules. For historical scanning, Gitleaks can also scan the full Git history of a repository to find secrets committed in the past.
What is the difference between SAST and SCA?
SAST (Static Application Security Testing) analyses source code your team wrote, looking for patterns that indicate vulnerabilities such as injection flaws, insecure deserialisation or hardcoded configuration. Tools like Semgrep and CodeQL work at the code level. SCA (Software Composition Analysis) analyses the third-party libraries and packages your application depends on, checking their versions against known CVE databases. Tools like Trivy and Grype work at the dependency manifest and binary level. Both are needed because your own code and your dependencies are separate attack surfaces.
Building a new project and want security controls wired in from sprint one? Stonetusker's Secure Delivery practice builds production-grade DevSecOps pipelines within a fixed 90-day engagement.
Talk to StonetuskerSources and Related Reading
External sources: