DevSecOps: securing the software supply chain end to end

1. Shift-left #

Security is everyone's business.

Principles #

DevSecOps integrates security at every step instead of an audit at the end of the project. A vulnerability detected in the pull request costs a few minutes; the same discovery in production costs an incident.

• Threat modeling at design time (STRIDE, a few simple questions: what can go wrong?).
• Fast, automatic checks in the pipeline, with clear thresholds.
• Automatically proposed fixes (Dependabot, Renovate).
• A security team that provides tools and support rather than blocking at the end of the chain.

2. The checks #

What is analyzed and with what.

Overview #

From the command line #

gitleaks detect --source . --redact                    # secrets
semgrep scan --config auto --error                      # SAST
trivy fs --scanners vuln,secret,misconfig --severity HIGH,CRITICAL --exit-code 1 .
trivy image --severity CRITICAL --exit-code 1 ghcr.io/mon-org/shop-api:3f9c2e1
checkov -d infra/                                       # IaC

Handling results #

Good practice: Block only on what is serious and fixable (CRITICAL with a fix available), display the rest. A pipeline that blocks on hundreds of alerts is quickly bypassed.

Document exceptions (.trivyignore, annotations) with a justification and an expiry date.

3. The software supply chain #

Knowing what you ship, and proving it.

SBOM #

An SBOM (Software Bill of Materials) is the inventory of all components of an artifact, in SPDX or CycloneDX format. When a new flaw is published (Log4Shell), it tells you within minutes which images are affected.

syft ghcr.io/mon-org/shop-api:3f9c2e1 -o spdx-json > sbom.spdx.json
grype sbom:sbom.spdx.json       # analyser une SBOM existante

Signing and provenance #

# Cosign (Sigstore) : signature sans clé avec l'identité OIDC de la CI
cosign sign --yes ghcr.io/mon-org/shop-api@sha256:4b1c...
cosign attest --yes --type spdxjson --predicate sbom.spdx.json ghcr.io/mon-org/shop-api@sha256:4b1c...
cosign verify ghcr.io/mon-org/shop-api@sha256:4b1c... \
  --certificate-identity-regexp 'https://github.com/mon-org/.*' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com

The SLSA framework defines levels of assurance on provenance: scripted build, run on a CI platform, signed provenance attestation, isolated and tamper-proof build.

Admission policies #

# Kyverno : n'accepter que des images signées par notre CI
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata: { name: images-signees }
spec:
  validationFailureAction: Enforce
  rules:
    - name: verifier-signature
      match: { any: [{ resources: { kinds: [Pod] } }] }
      verifyImages:
        - imageReferences: ["ghcr.io/mon-org/*"]
          attestors:
            - entries:
                - keyless:
                    subject: "https://github.com/mon-org/*"
                    issuer: "https://token.actions.githubusercontent.com"

4. Secrets #

The first compromise vector.

Rules #

• No secrets in Git, images or logs; detection in pre-commit and in CI.
• A secrets manager (Vault, AWS Secrets Manager, Azure Key Vault, External Secrets Operator).
• Short-lived, automatic credentials (OIDC, cloud roles) rather than long-lived keys.
• Regular rotation and immediate rotation after a leak: deleting the commit is not enough, the secret must be revoked.

Common mistake: A secret pushed to a public repository is harvested by bots within minutes. Revoke it first, clean the history afterwards.