Secure-by-design SDLC needs security gates and automation

At a glance

What this is: This is a DevSecOps architecture post arguing that security gates and automation must be built into the SDLC to make software secure by design.

Why it matters: For IAM and NHI practitioners, the same control logic applies to secrets, service accounts, and agent access because prevention only works when checks happen before credentials and code reach production.

👉 Read GitGuardian's DevSecOps architecture post on security gates and automation

Context

A secure-by-design SDLC means security is enforced as part of the development path, not added after release. In practical terms, that matters for NHI governance because secrets, service accounts, and automation tokens often move through the same pipeline as application code, where a missed control can persist into production.

The article frames two control families as essential: security gates and automation. That is a familiar pattern for NHI practitioners because the problem is not only detection, but timing. If access, secrets, or policy failures are only found after deployment, the remediation cost rises and the blast radius is already set.

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. Put hard blocks at the first point you can reliably control, usually pull request or admission time, then add earlier checks where they improve speed without creating excessive friction. The best programmes align each gate to a specific risk and keep the feedback consistent across tools.

Q: When does pre-commit scanning make more sense than pre-push scanning?

A: Pre-commit scanning makes more sense when the risk is irreversible or expensive to clean up later, especially with secrets and API keys. If a sensitive credential reaches git history, revocation and rotation become cleanup work. Pre-push scanning is better for checks that are useful but would be too heavy during frequent local commits.

Q: What is the difference between build-time scanning and deployment-time policy checks?

A: Build-time scanning evaluates the artifact when it is created, while deployment-time policy checks evaluate whether that artifact should be admitted into the running environment. Both matter because risks can appear after build or drift between build and release. Teams need both if they want confidence that the deployed state still meets policy.

Q: Why do secure-by-design programmes need automation as well as controls?

A: Controls without automation create friction, and friction leads to bypasses, delays, and inconsistent enforcement. Automation turns security from a manual review exercise into a repeatable workflow that can provide warnings, fixes, and policy feedback at the pace of development. That is what makes the model sustainable.

Technical breakdown

Security gates in the SDLC

Security gates are enforceable checks placed at specific pipeline stages so code cannot advance unless it meets a defined security baseline. In this model, pull request checks provide the first hard control point, while pre-commit, pre-push, container image, and Kubernetes admission checks add earlier or later validation depending on when a rule can be applied. The technical value is not just scanning, but enforcing consistent release criteria across the pipeline. For NHI-adjacent risks, that means credentials and policy violations should be blocked before they become embedded in code, images, or deployment manifests.

Practical implication: Treat each pipeline stage as a separate control point and decide which findings must block progression versus warn only.

Pre-commit and pre-push hooks for secret detection

Pre-commit and pre-push hooks are local automation triggers that run before code is committed or pushed to the repository. The article correctly distinguishes their security value: secret scanning is most effective at pre-commit because a leaked secret can otherwise enter git history, while some broader analysis may be more practical at pre-push to reduce developer friction. The architectural point is that the earlier the control runs, the cheaper the fix, but not every scanner belongs in every hook. For NHI governance, that timing matters because once a token or API key is committed, revocation and rotation become mandatory cleanup work.

Practical implication: Use pre-commit for secret scans and reserve heavier checks for later hooks where they will not break normal developer flow.

Kubernetes admission control and deployment-time policy

A Kubernetes admission controller validates or mutates deployment requests before the workload is admitted to the cluster. In the article’s model, it checks container images for vulnerabilities that may have appeared since build time and can also enforce infrastructure-as-code policy, which makes it a deployment-time backstop rather than a replacement for earlier scanning. That layered design matters because build-time assurance can go stale. For NHI and workload identity governance, admission control is the last practical place to stop unsafe workloads, misconfigured access, or policy-breaking images from reaching an exposed environment.

Practical implication: Use admission control as the final enforcement layer, especially for configuration drift and late-breaking dependency risk.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Secure-by-design is really a governance model for failure timing. The point is not to eliminate all risk before release, because that is unrealistic. The point is to decide which risks are allowed to move forward, which are blocked, and which are only observed. For NHI programmes, that same distinction separates manageable credential hygiene from silent production exposure.

Identity controls belong in the pipeline, not just in the identity platform. The article shows that a control can be technically sound and still fail if it arrives too late in the workflow. Secrets, tokens, and service account changes need to be governed where they are created, committed, built, and deployed, because the control plane has to match the pace of software delivery.

Developer experience is part of the security architecture. The post makes a useful operational point: overloading early hooks creates friction, and friction drives workarounds. That is also true in NHI governance, where teams ignore controls that interrupt delivery without clear benefit. The practical lesson is to balance enforcement with consistent feedback and tooling.

Pipeline consistency is the real control multiplier. When the same findings appear in local tools, CI, and deployment checks, teams learn to remediate once and trust the result. That consistency reduces false surprises and strengthens operational discipline. For security architects, the implication is clear: if the control is not repeatable, it is not yet a control.

Automation should shorten remediation, not just detect defects. The strongest DevSecOps pattern is not scanning in isolation, but pairing detection with fix suggestions, workflow integration, and agreed thresholds. That approach maps directly to NHI management, where identification without rotation, revocation, or offboarding leaves the organisation with awareness but no control.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to the Ultimate Guide to NHIs.
• Only 20% of organisations have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• That is why lifecycle controls deserve the same operational treatment as build controls, as explained in the Ultimate Guide to NHIs.

What this signals

Ephemeral control is the right mental model for pipeline security. Security gates only reduce risk when they are tied to a clear lifecycle event, such as commit, merge, build, or deployment. In NHI programmes, that means secrets and workload credentials should be evaluated at the same moments the software changes, not on a separate calendar.

The governance lesson is that developer tooling and identity controls now share the same operational surface. If your programme cannot see secrets at commit time, cannot stop vulnerable images at admission time, and cannot keep remediation consistent across environments, then it will struggle to govern service accounts and agent access with any confidence.

A useful benchmark is that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs. That is a pipeline problem as much as an identity problem, and it is why NHI governance must be embedded in delivery workflows.

For practitioners

• Map security gates to SDLC stages Define which checks must block at pull request, pre-commit, pre-push, build, and admission time. Assign each gate a specific purpose so secret scanning, dependency checks, and deployment policy do not overlap blindly.
• Move secret detection as far left as possible Run secret scanning in pre-commit hooks so API keys and tokens never enter git history when practical. Reserve pre-push or CI checks for broader validation where local enforcement would be too disruptive.
• Standardise findings across tools Use the same severity logic and remediation language in IDE plugins, CI workflows, and admission control so developers see one coherent message. Consistency reduces rework and makes enforcement easier to trust.
• Pair blocking rules with automated fixes Automate dependency updates, remediation hints, and owner routing so a failed gate leads to action instead of backlog growth. This is especially important for secret and access findings, where delay increases exposure.

Key takeaways

• Secure-by-design SDLC is about enforcing security requirements at the points where software changes hands.
• Secret scanning is most effective when it happens before sensitive material becomes part of git history.
• Consistent automation across local, CI, and deployment layers is what makes developer-facing controls sustainable.

Key terms

• Security Gate: A security gate is an enforceable checkpoint in a delivery pipeline that prevents software from advancing until it satisfies a defined control. In DevSecOps, gates can apply at commit, pull request, build, or deployment time, depending on when a check can be trusted to produce a meaningful result.
• Pre-commit Hook: A pre-commit hook is an automated local check that runs before code is written into git history. It is especially useful for catching secrets, because once a token or key is committed, removal becomes a revocation problem as well as a code cleanup problem.
• Admission Controller: An admission controller is a Kubernetes control that validates or changes workload requests before the cluster admits them. It acts as a deployment-time policy layer, which makes it useful for blocking unsafe images, rejecting risky configuration, and enforcing runtime standards that build-time scans may miss.
• Secure-by-Design: Secure-by-design means security requirements are built into the development process rather than added after release. The practical aim is to define minimum acceptable controls early, then enforce them consistently so products cannot ship without passing baseline security checks.

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 PR checks, pre-commit hooks, and admission controller placement across the SDLC
• The specific scan types used at each stage, including when to use secret detection versus dependency checks
• Developer workflow guidance on reducing friction while still enforcing blocking security thresholds
• The article's implementation sequence for introducing warnings before hard blocks in a live engineering environment

👉 GitGuardian's full post covers the SDLC stages, hook choices, and deployment controls in more implementation detail

Deepen your knowledge

Secure-by-design SDLC and secret handling are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building pipeline controls around service accounts, tokens, and API keys, it is worth exploring.