Security on Every
Pull Request
DevSecOps programme build-out and CI/CD pipeline hardening. SAST + SCA tuned to your stack, secret scanning at the keyboard, IaC policy-as-code at the PR gate, and runtime DAST against ephemeral preview environments — all mapped to OWASP SAMM, BSIMM, NIST SSDF SP 800-218 and SLSA. Security feedback in seconds, not sprints.
- <5 second
- pre-commit feedback
- 300+ → <20
- scanner noise, tuned
- +30s per PR
- median developer impact
- SLSA L3
- build-integrity target
Service overview
An AxVeil DevSecOps engagement is a programme, not a tool deployment. We start from where you actually are — typically a CI pipeline with one or two security scanners bolted on, producing alert fatigue without ownership — and rebuild it as a layered defence with clear severity thresholds, tuned rule packs, policy-as-code gates and measurable developer-cycle impact. The output is not a wall of dashboards; it is a pipeline where the build breaks for the right reasons and only the right reasons, every time.
OWASP SAMM v2 frames the maturity model: Governance, Design, Implementation, Verification and Operations, each scored Level 0-3 across five business functions. The typical 12-month target is SAMM Level 2 across all five — measurably better than industry baseline, achievable inside a single fiscal year, defensible to an auditor or board. NIST SSDF SP 800-218 supplies the practice groups (PO, PS, PW, RV) that US federal procurement now requires under Executive Order 14028. SLSA v1.0 sets the build-integrity bar per repo class. ISO 27001:2022 Annex A.8.28 maps for secure-coding evidence.
The work is opinionated. Pre-commit hooks ship first — gitleaks for secret detection, signed-commit enforcement, conventional-commit linting — because feedback at the keyboard is faster than feedback at the PR. SAST and SCA come next, tuned hard against the noise floor: a stock Semgrep configuration produces 300+ findings on most repos, and the work is cutting that to under 20 actionable items per repo with a documented allowlist for the rest. IaC scanning and policy-as-code via OPA gate the infrastructure layer. Runtime DAST wired into CI against ephemeral preview environments closes the loop on what static analysis cannot see.
Sub-offerings
SAST + SCA tuning
Semgrep or CodeQL configured per repo with custom rule packs for your framework idioms. SCA via OSV-Scanner, Trivy or Snyk Open Source. SBOM emitted in SPDX 2.3 + CycloneDX 1.5 on every build. False-positive tuning is the deliverable: stock 300+ findings cut to under 20 actionable per repo within four weeks. Build breaks only above the agreed severity threshold; informational findings surface as PR annotations, not blockers. Reachable-call-graph correlation where the scanner supports it — a CVE in unreachable code does not break the build.
Secret scanning + pre-commit hooks
gitleaks installed on every developer workstation via pre-commit framework, scanning staged changes in under 5 seconds. ggshield or trufflehog as second-line at the CI gate. Signed-commit enforcement (GPG or Sigstore gitsign) on protected branches. Branch protection rules: required reviewers, status checks, no force-push. Leaked-credential incident playbook: revocation, rotation, post-mortem, and a documented blast-radius assessment for every leak that escapes pre-commit.
IaC scanning + policy-as-code
Checkov, tfsec and Trivy IaC against Terraform, CloudFormation, Helm charts, Kustomize overlays and raw Kubernetes manifests. Open Policy Agent (OPA) with a version-controlled Rego policy library enforced at PR gate. Kyverno or Gatekeeper at the cluster admission layer for defence-in-depth. CIS Benchmark coverage for AWS, Azure, GCP and Kubernetes. Policy library lives in its own repo, consumed by every pipeline via a pinned reference — single source of truth, auditable change history.
Runtime DAST in CI/CD
Authenticated ZAP automation framework or Burp Suite Enterprise scans against ephemeral preview environments on every pull request. Schema-driven API fuzzing where OpenAPI / GraphQL definitions exist. Findings routed to DefectDojo and surfaced back to the developer as a PR comment in the same review cycle. Nightly full-depth scans against staging triaged the next morning. The static layer catches what the code says; DAST catches what the running system actually does.
Methodology
Seven phases derived from OWASP SAMM, BSIMM and NIST SSDF SP 800-218, calibrated to a typical 12-week pipeline-hardening engagement followed by an ongoing operate-and-iterate cadence.
Frameworks & standards
Programme structure and tooling align to the standards your auditor, procurement team and enterprise customers will ask for.
Deliverables
A working pipeline, not a slide deck. Every deliverable is version-controlled in your own repos so the programme outlives the engagement.
package terraform.s3
# Deny S3 buckets without server-side encryption.
# Source: CIS AWS Foundations Benchmark v3.0 § 2.1.1
deny[msg] {
resource := input.resource.aws_s3_bucket[name]
not resource.server_side_encryption_configuration
msg := sprintf(
"S3 bucket '%s' must have server_side_encryption_configuration (CIS 2.1.1)",
[name],
)
}Frequently asked questions
What is DevSecOps, and how is it different from running a SAST tool in CI?+
DevSecOps is the integration of security practices, tooling and accountability across the entire software delivery lifecycle — from developer workstation through commit, build, test, deploy and runtime. Running a SAST scanner in CI is one control inside that programme; on its own it produces noise without ownership. An AxVeil DevSecOps engagement builds the programme around the tools: pre-commit feedback, tuned scanners with custom rule packs, policy-as-code gates, SBOM emission, secret leak prevention, IaC compliance, and runtime DAST — all wired to clear severity thresholds, ownership and SLAs. OWASP SAMM, BSIMM and NIST SSDF SP 800-218 frame the maturity model.
How long does a typical pipeline-hardening engagement take?+
A 12-week build-out is the standard shape for a Series-A to Series-C SaaS with 5–25 repositories. Weeks 1-2: SAMM assessment, pipeline inventory, tool selection matrix. Weeks 3-6: pre-commit hooks, branch protection, SAST + SCA tuned per repo. Weeks 7-9: IaC scanning + OPA policy library + admission controller. Weeks 10-11: ZAP / Burp Enterprise wired into CI against preview environments. Week 12: runbooks, metrics dashboard, handover. After handover we offer an optional quarterly retainer to keep tooling current, tune false positives as the codebase evolves, and run tabletops on the pipeline itself.
Which frameworks do you map the programme to?+
OWASP SAMM v2 is the maturity model — Governance, Design, Implementation, Verification and Operations, with five business functions each scored Level 0-3. BSIMM is used as a benchmarking lens against industry peers. NIST SSDF SP 800-218 supplies the practice groups (PO, PS, PW, RV) and is the framework most US federal procurement now requires (EO 14028). SLSA v1.0 sets the build-integrity bar per repo class. ISO 27001:2022 Annex A.8.28 secure coding is mapped for ISO-certified clients. PCI DSS v4.0 Requirement 6 maps where in scope.
Will the new gates slow down our developers?+
The opposite is the design goal. Pre-commit hooks return feedback in under 5 seconds on the developer workstation — they fix the issue before the PR exists, which is faster than waiting for a CI failure. SAST + SCA in CI is tuned hard: the build only breaks above an agreed severity threshold (typically Critical and High by default), informational findings are surfaced as PR annotations not blockers. Median developer-cycle impact across past engagements is +30 seconds per PR after week 4, with a measurable reduction in production hotfixes within the first quarter. We track this with DORA metrics (deployment frequency, lead time, change failure rate) before and after.
How do you handle false positives from SAST and SCA tools?+
False-positive tuning is the work, and we treat it as a first-class deliverable. Week one of SAST rollout typically produces 300+ findings per repo from a stock ruleset — most are not actionable. We build a per-repo allowlist with documented justification (path, rule ID, reason, expiry), promote custom rules for your framework idioms, and configure the scanner to fail only on high-confidence findings above the severity threshold. Within four weeks the noise floor is typically under 20 actionable findings per repo, with the allowlist reviewed quarterly. SCA findings are correlated against reachable-call-graph analysis where the scanner supports it — a vulnerable function in an unreachable dependency does not break the build.
Do you build to SLSA Level 3, and what does that cost in pipeline complexity?+
SLSA L3 is achievable for build-critical repos and is increasingly required by US federal procurement, large enterprise vendors and SOC 2 + supply-chain attestations. It requires hermetic builds, signed provenance attestations (in-toto / SLSA format), tamper-resistant build platforms (GitHub Actions with OIDC + Sigstore, or Google Cloud Build with Binary Authorization), and source/build provenance verification at deploy time. For most clients we target SLSA L3 on build-critical artefacts (the main product) and L2 on internal tooling. The complexity overhead is real but bounded — typically two weeks of pipeline work per repo class plus a Sigstore / cosign signing infrastructure setup that is shared across the org.
Related
Scope your DevSecOps engagement
Send the repo inventory, target SAMM level and current CI platform. We respond with a fixed-fee proposal, a 12-week delivery plan and a sample policy library from a comparable engagement.
Request a scoping call →