Topic starter
16/12/2025 5:20 pm
TL;DR: GitGuardian argues that a secure-by-design SDLC depends on automated security gates at pull request, pre-commit, build, and deployment stages so developers cannot move vulnerable code or leaked secrets forward unchecked. Security requirements have to become release criteria, because late review leaves too much already committed to git history or published into runtime.
Editorial analysis by NHI Mgmt Group, based on content published by GitGuardian: “Secure-by-Design Software in DevSecOps”.
Key questions
Q: How should security teams implement security gates in a DevSecOps pipeline?
A: Start by deciding which pipeline stages are enforceable and which are advisory.
Q: Why do security gates reduce risk better than post-release scanning alone?
A: Because they stop vulnerable code, dependencies, and secrets before they become durable in git history, build artefacts, or deployed workloads.
Q: What happens when secret scanning is placed too late in the pipeline?
A: Secrets can already be committed, replicated, and shared before the control runs, which makes rollback harder and often forces revocation and rotation instead of simple prevention.
Practitioner guidance
- Define release-blocking security thresholds Agree which findings will stop a merge, build, or deployment before they reach production, and make the criteria explicit for engineering and security teams.
- Place secret scanning at commit time Run secret detection before code enters git history so exposed credentials can be stopped before they become durable and difficult to remove.
- Align scanner output across pipeline stages Use the same scan logic and result format in local tools, pull requests, builds, and deployment checks so developers do not face conflicting findings.
Bottom line: Secure-by-design delivery depends on enforceable security gates, not just more scanning, because the pipeline must be able to stop unsafe changes before they become durable.
What's in the full article
GitGuardian's full blog post covers the operational detail this post intentionally leaves for the source:
- Step-by-step examples of where to place pre-commit, pre-push, pull request, build, and admission checks in a DevSecOps pipeline
- The article's stage-by-stage walkthrough of security gates for code, container images, and Kubernetes deployment
- Practical guidance on balancing developer friction against blocking thresholds when introducing automation
- The full discussion of how to use consistent scanner output to reduce context switching for engineering teams
👉 Read GitGuardian's guide to secure-by-design SDLC security gates and automation →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 10 months ago by GitGuardian
This topic was modified 5 days ago by NHI Mgmt Group
07/10/2026 6:24 pm
Secure-by-design SDLC is a governance change before it is a tooling change. The central shift is redefining production-ready so security becomes part of the release requirement, not an after-the-fact review. That changes developer behaviour, pipeline design, and accountability at the same time. Practitioners should treat release gating as a policy decision, not a scanner deployment exercise.
A few things that frame the scale:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
A question worth separating out:
Q: Should developers see the same security findings at every pipeline stage?
A: Yes, because inconsistent results create confusion and erode trust in the controls. If a workstation scan, build scan, and admission check disagree, engineers will waste time reconciling tools instead of fixing issues. Consistency in findings, severity thresholds, and presentation is part of control effectiveness.
👉 Read our full editorial: Secure-by-design SDLC needs security gates and automation