Developer-first security means putting security checks where developers already work, in the editor, the pull request and the pipeline, with fast and specific feedback, instead of a late review by a separate team. It does not remove security ownership. It moves the first feedback loop to the person who can fix the issue cheaply.
What does the standard say?
NIST SP 800-218, the Secure Software Development Framework, is written as practices any team can adopt, not as a gate at the end. Several map neatly onto developer workflow:
- PW.4.1: acquire and maintain well-secured software components from commercial, open source and other third parties. It suggests reviewing third-party components in the context of how they will be used, and repeating the review if use changes.
- PW.5.1: follow secure coding practices appropriate to the language and environment.
- PS.1.1: store all code, including source, executable and configuration as code, under least privilege so only authorized people, tools and services have access.
- RV.1.1: gather vulnerability information from users, public sources and acquirers about the software and its third-party components, and investigate all credible reports. Examples include monitoring vulnerability databases and automating the process.
None of these says "run a scanner once per release."
Where does each check belong?
Constructed example for one change: a developer adds an HTTP client library to fix a feature.
In the editor. The moment the dependency is added, the developer learns the version has a known flaw and a patched version exists. Fixing it costs a one-line change. This is where feedback is cheapest.
In the pull request. The change is checked against team policy: no unapproved licenses, no packages outside the allowed set, no new high-risk findings in code that is actually reachable. Reviewers see the result inline, next to the diff.
In the pipeline. Build and test run on a hosted runner with limited credentials. The pipeline records provenance, which SLSA describes as showing what entity built the artifact, what process they used and what the inputs were. At SLSA build level 1 provenance exists. Level 2 adds signed provenance from a hosted build platform. Level 3 adds a hardened build platform that resists tampering during the build.
After release. New disclosures arrive against code that has already shipped. RV.1.1 expects someone to keep watching.
Why does speed matter?
If a check takes twenty minutes and returns a hundred findings, engineers learn to ignore it, or to route around it. Developer-first design asks for the opposite: results in seconds where possible, only findings the developer can act on, a suggested fix, and a clear path to an exception with an owner and an expiry. Fewer, better findings protect trust in the tool.
How does this stay secure?
Developer-first is not developer-only. Security teams still own the policy, the exception process, the pipeline hardening and the review of what the tooling misses. The aim is to make the safe path the default one, and to keep humans for decisions that need judgment.
Where Safeguard fits
Safeguard's IDE extensions for VS Code, Open VSX and Cursor, and JetBrains, its CLI and local runner, and its pull request policies and gates are built for this loop. Reachability analysis helps cut findings down to the ones your code can reach, and autonomous remediation can propose fix pull requests, which stay off by default until you turn them on.
See it in the gate pull request demo.
How to check or apply this
- Pick the three checks that matter most: vulnerable dependencies, secrets and risky code patterns.
- Run each in the editor or the pull request first, not only in nightly jobs.
- Set a time budget for the pull request stage, and cut checks that blow it.
- Make every blocking rule explainable in one sentence, with a documented exception path.
- Lock down the pipeline itself: least privilege for runners, no long-lived secrets, signed provenance.
- Track the median time from finding to fix, and the share of findings dismissed as noise.
- Review the rules every quarter with developers in the room.
Quick check
Does developer-first mean developers are solely responsible for security?
No. It means they get the first and fastest feedback. Security teams still set policy, harden the pipeline and handle what automated checks miss.
What is the first check to move left?
Dependency checks usually give the quickest return, because a patched version often exists and the fix is a small change made at the moment the package is added.
Sources
- NIST SP 800-218, Secure Software Development Framework (SSDF) Version 1.1
- SLSA specification v1.0: levels
- SLSA: about
Last reviewed: 18 October 2026.
