DevSecOps security built into CI/CD

DevOps + a scanner at the end is what many call DevSecOps in marketing, but it is not. Real DevSecOps means integrating security in every stage of the cycle: team culture (devs + ops + sec talking daily, sharing metrics and ownership), tooling embedded into the natural flow of work (not standalone audit scans), policy as code, control automation. A scanner at the end generates friction and gets ignored; a control properly integrated pre-commit, in PR and in the pipeline catches the issue while it still costs minutes to fix, not weeks.

Three lines of work. Diagnostic: we measure current DevSecOps maturity against OWASP SAMM or BSIMM and return a prioritised roadmap. Implementation: we add controls at every pipeline stage (pre-commit hooks, SAST, SCA, secrets scanning, IaC scanning, DAST, container scanning, artefact signing, secrets management, policy as code). Operation: the team owns the flow, and we govern it: finding triage, rule tuning to reduce false positives, continuous improvement. Two contractual models: continuous operation programme or periodic point-in-time audits.

Whatever the client uses. CI/CD: GitHub Actions, GitLab CI, Jenkins, Azure DevOps, Bitbucket Pipelines, CircleCI, ArgoCD. SAST/SCA/secrets: Semgrep, SonarQube, CodeQL, Snyk, OSV-Scanner, Trivy, Gitleaks, TruffleHog. IaC scanning: Checkov, tfsec, KICS, Terrascan. Container/K8s: Trivy, Grype, Falco, Kyverno, OPA Gatekeeper. DAST: ZAP, Burp Suite Enterprise, Nuclei. Signing and SBOM: cosign/sigstore, syft, CycloneDX, SPDX. Secrets management: Vault, AWS/Azure/GCP Secrets Manager, CyberArk. We do not impose tooling: we work with what the team already knows or whatever is closest to the stack.

Well implemented, the opposite: total delivery time goes down because problems are caught in minutes rather than weeks. Badly implemented it does slow things down, which is why the first month is spent tuning rules so false positives drop below the threshold the team tolerates (typically <15%), keeping blocking controls only on critical items (secrets, critical dependencies), and giving developers visibility and control over what runs when. The criterion: the average developer should never face an absurd alert.

A maturity diagnostic: 2-3 weeks, €6-12k. Initial implementation for a typical stack (1-3 repos, GitHub/GitLab Actions, main cloud): 6-12 weeks, 1-2 engineers, €24-60k. Large platforms with multiple languages, monorepos and several cloud environments take 12-24 weeks and €60-140k. Subsequent continuous operation is billed as a monthly subscription; periodic audits as fixed-scope projects. Before quoting we run an initial diagnostic to size the real scope.

Five tracked by the security team and another five tracked by development and operations. Security: % vulnerabilities detected pre-production, MTTR for vulnerabilities by severity, % builds blocked by critical findings, % secrets prevented vs detected after the fact, control coverage per service. Development/operations: lead time to secure deploy (total time from commit to approved production), deploys per week (classic DORA metric), change failure rate, mean time to recover, developer satisfaction with security controls (measured formally, not assumed).

It maps directly to the secure development management block. ISO 27001:2022 (A.8.25 to A.8.30) covers planning, environment separation, configuration and security testing in development. NIS2 art. 21.2.f requires policies and procedures to assess the effectiveness of measures. DORA art. 9 + 24-27 covers the testing and resilience programme. PCI DSS v4 req. 6 is entirely secure development and maintenance. What we deliver — documented pipeline, evidence of executed controls, finding management, measured continuous improvement — is exactly what every auditor asks for.

On the existing one whenever viable. If you already have GitHub Actions/GitLab CI/Jenkins with consolidated flows, we add the controls within those flows without rewriting them. If the base is very weak (no real CI/CD, manual builds, manual deployments), we recommend consolidating the DevOps flow first and then layering Sec on top. We do not impose the CI/CD tool: we work with what the team will maintain after we leave.

The continuous programme is for clients who want to treat DevSecOps as a living practice: we operate the flow, triage findings, tune rules, surface structural alerts, train the team. It delivers the best result in sustained maturity. Periodic audits are for clients with a capable team that prefers to own the operation and contract external reviews periodically (typically quarterly or half-yearly): the scope is to review the pipeline, identify drift, validate that controls remain active and operational, and deliver an executive report + improvement plan. Same Hard2bit team, same technical level, different contractual models.

A 30-minute call to understand your stack, the moment (post-incident, regulatory requirement, modernisation, scale) and the model that fits. If it makes sense, a 1-2 hour technical walkthrough with a tech lead and a sysadmin/SRE. From there we issue a firm proposal in 48-72 hours: initial diagnostic, implementation scope, assigned team, deliverables and fixed price. If we see it makes sense to combine with a point-in-time code audit before deploying the pipeline, we will say so honestly.