Rule customization is the missing factor in developer-friendly security

At a glance

What this is: This is a developer-security analysis arguing that rule customization is the key to making application security tools fast, relevant, and usable.

Why it matters: It matters because security teams that cannot tailor findings to developer workflows will keep generating noise, delaying remediation, and weakening adoption across application and identity-adjacent engineering programmes.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• Only 5.7% of organisations have full visibility into their service accounts.

👉 Read Semgrep's guide to rule customization for developer-friendly security

Context

Developer-friendly security tooling starts with a simple governance problem: finding issues is not the same as changing developer behaviour. When scans are slow, noisy, or disconnected from the coding environment, teams treat them as interruptions rather than controls. The article is really about application security operations, but it also intersects with identity governance where code, secrets, service accounts, and remediation workflows meet.

That intersection matters because many of the failures described here are not just code quality problems. They are access and secret-handling problems, especially when developers need immediate, contextual guidance on what to fix and why. In NHI-heavy environments, tooling that cannot surface actionable checks for secrets, tokens, or workload credentials will miss the operational reality that identity exposure is happening inside software delivery, not outside it.

Key questions

Q: How should security teams make offensive security findings actionable?

A: They should connect each finding to ownership, context, remediation tracking, and retesting. Offensive security only changes outcomes when results are mapped to the right system or identity owner and followed through to closure. Without that loop, teams collect reports but do not reduce exposure.

Q: Why do customised rules improve developer adoption of security tools?

A: Customised rules improve adoption because they reduce irrelevant noise and reflect the realities of local code, libraries, and workflows. When developers see findings that map to their actual work, trust rises and fix rates improve. Without that fit, even accurate tools are often ignored.

Q: What breaks when security tools are too generic for the code they scan?

A: Generic tools often miss project-specific unsafe patterns and overload developers with findings they cannot easily fix. That weakens trust, delays remediation, and turns security into a review bottleneck. In practice, the tool becomes a detector of risk rather than a control that changes behaviour.

Q: How can organisations measure whether AppSec controls are working?

A: They should look for fewer repeat vulnerabilities, lower false-positive burden, faster developer adoption, and measurable reduction in high-risk bug classes. A healthy AppSec programme changes the shape of risk, not just the number of alerts. If findings remain high but exposure does not fall, the control model is not scaling.

Technical breakdown

Why rule customization changes the economics of AppSec

Traditional scanners are optimized to detect known patterns at scale, but they are not automatically optimized for developer action. Rule customization lets teams encode in-house libraries, expected argument values, banned calls, or required remediation patterns. That reduces false positives, increases relevance, and shifts the tool from a generic detector to a control that fits the local codebase. In practice, the value is not just better detection. It is higher developer trust, faster triage, and a better chance that issues are fixed before release.

Practical implication: security teams should tune rules to local code and delivery patterns before expanding scan coverage.

How autofix and workflow embedding improve remediation

A finding is only useful if it can be acted on quickly. Autofix changes the model from alerting to guided remediation by applying a code transformation or suggesting a specific replacement. Embedding those suggestions into pull requests or IDEs keeps the fix in the developer’s normal workflow, which is where adoption rises. This is especially important for security issues that have a canonical safe replacement, such as cryptographic algorithm choices or unsafe secret-handling patterns. The control objective becomes fewer handoffs and less context switching.

Practical implication: prioritize fixes that can be applied at review time or directly inside the IDE.

Why detecting missing safeguards can beat finding vulnerabilities

In many cases, it is easier to prove that a safe pattern is absent than to prove a vulnerability exists in every execution path. That matters because software is often written before its eventual inputs, callers, or trust boundaries are fully known. If the control is framed as a required secure pattern, such as parameterization or an approved library, the tool can flag absence earlier and with less expensive analysis. This is a stronger model for prevention because it moves the decision point left in the development lifecycle.

Practical implication: build policy checks around required secure patterns, not only known vulnerable patterns.

NHI Mgmt Group analysis

Rule customization is a governance control, not a developer convenience. The article shows that generic security findings lose force when they ignore codebase context, internal libraries, and local remediation paths. That makes customization part of control design, not a nice-to-have feature. For application security programmes, the governing question is whether the feedback loop changes developer behaviour at the point of code creation.

Developer trust is the real performance metric: tools that cannot earn trust will not change outcomes. The article’s 60% fix-rate ceiling without customization is a useful reminder that detection volume is not the same as remediation value. The higher-value metric is whether developers can understand, accept, and fix what they are shown. In identity-adjacent software, that matters because secrets, tokens, and service-account handling often fail in the same low-trust feedback loops.

Fast, relevant, and usable security feedback is the new baseline for scalable control. Security teams have spent too long treating scan coverage as the success measure. The article argues for a different baseline: findings must arrive early, fit the workflow, and include a path to resolution. That aligns with modern governance expectations in software delivery, where control effectiveness depends on adoption rather than alert volume.

Semgrep’s rule customisation model reflects a broader shift from policy definition to policy enforcement in code. YAML rules, query languages, and APIs are just different ways of expressing the same governance need: encode the organisation’s secure defaults into the developer toolchain. For identity and secrets-heavy environments, that means treating code analysis as part of access governance for software, not just as a vulnerability hunting exercise. The practitioner conclusion is simple: if the control cannot be expressed where code is written, it will be expressed too late.

What this signals

Developer-friendly security will increasingly be judged by remediation quality, not tool volume. As teams tighten software supply chain and secrets governance, the tools that matter are the ones developers actually use at the point of change. That raises the bar for appsec programmes and for identity-adjacent controls that depend on code review, secret handling, and policy enforcement in the delivery pipeline.

Policy expressed in code is becoming the operational bridge between application security and identity governance. When a security rule can encode expected secret usage, approved libraries, or banned credential patterns, the organisation is no longer relying on memory or manual review. That aligns with broader identity security work where governance fails if it cannot be enforced in daily engineering practice. The relevant external baseline is the NIST Cybersecurity Framework 2.0, especially its protect and recover outcomes.

Fix-rate telemetry is a better programme signal than alert count. If your team cannot show that developers are accepting and applying secure guidance, the control is not operating at the right layer. The operational priority is to close the gap between detection, guidance, and remediation, because that is where identity secrets and code-level vulnerabilities persist longest.

For practitioners

• Implement rule customization for internal code paths Encode in-house libraries, approved arguments, and banned patterns so scanners understand your actual application architecture rather than a generic baseline.
• Push remediation into pull requests and IDEs Return findings where developers already work, including GitHub PR comments or IDE feedback, so security guidance becomes part of review and editing rather than a separate queue.
• Measure effective false positives instead of raw findings Track how many alerts developers can actually act on and how often they accept the recommended fix, because alert volume alone does not measure control quality.
• Prefer policy checks for missing safe patterns Write controls that flag the absence of parameterized queries, approved libraries, or other required secure outcomes when that is easier than proving exploitation.
• Add autofix for deterministic remediation paths Where a safe replacement is clear, use automated transformations so the tool can propose or apply the fix immediately instead of leaving developers to interpret the alert.

Key takeaways

• Rule customization is what turns AppSec tooling from a detector into a usable control.
• Developer trust depends on relevance, speed, and fixability, not on the number of findings produced.
• For identity-heavy software, the real governance question is whether security feedback changes code before secrets and access paths are exposed.

Key terms

• Rule Customization: Rule customization is the practice of tailoring security detections to the specific code, libraries, and workflows used by a team. It lets organisations encode local risk conditions and safer patterns so findings are more relevant, more trusted, and easier to remediate in practice.
• Effective False Positive Rate: Effective false positive rate is the proportion of alerts that developers cannot or will not act on, even if the underlying issue is technically real. It is a practical measure of control quality because unusable findings behave like noise, not governance.
• Autofix: An automated remediation workflow in which a machine reviewer not only identifies an issue but also applies a code change. In practice, this shifts the tool from advisory review into delegated execution, which requires clear permission boundaries, auditability, and rollback controls.

What's in the full article

Semgrep's full post covers the implementation detail this analysis intentionally leaves for the source:

• Rule-writing examples across API, custom query language, and YAML-based approaches for tailoring detections.
• Concrete examples of autofix and developer workflow integration that reduce remediation friction.
• Practical comparisons of customization approaches for teams deciding how much rule logic to encode.
• The article's original code snippets and tool-specific syntax for building custom rules.

👉 Semgrep's full post includes rule examples, autofix approaches, and customization trade-offs.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management in a way that supports practitioners working across identity, engineering, and security operations. It is designed for teams that need to connect governance intent to day-to-day control decisions.