Choosing SAST tools: the governance gaps teams must test

At a glance

What this is: This is a practitioner framework for selecting static application security testing tools, with the key finding that poor fit creates friction, delays, and weak adoption.

Why it matters: It matters to IAM and security teams because AppSec tooling increasingly intersects with secrets exposure, developer access patterns, and the controls that govern code, pipelines, and privileged source access.

👉 Read Semgrep's framework for selecting a static analysis tool

Context

Static application security testing, or SAST, only works when it matches how developers build, review, and ship code. The primary governance gap is not whether a tool can find defects in a lab, but whether it can operate across languages, frameworks, CI systems, and development workflows without creating so much noise that teams ignore it. In practice, that is a control adoption problem as much as a code analysis problem.

The identity intersection appears when SAST tools need access to source code, repositories, IDEs, and cloud-connected build systems. Those touchpoints create secret-handling and access-governance questions that belong in IAM and PAM review, especially where vendors or platforms require broad read access to code and pipelines.

Key questions

Q: How should security teams choose a SAST tool without creating developer friction?

A: Start with the delivery model, not the feature list. Test the tool in real repositories, IDEs, and CI pipelines, then measure false positives, scan latency, and review effort. If engineers cannot use it comfortably in normal workflows, adoption will drop and the scanner will become a reporting exercise rather than a control.

Q: Why do SAST programmes fail when language and framework coverage is incomplete?

A: Because incomplete coverage forces teams to run multiple scanners, write manual compensating rules, or accept blind spots in important parts of the codebase. That increases operational overhead and weakens consistency across applications. Good coverage is not about breadth for its own sake. It is about matching the actual stack you ship.

Q: What do teams get wrong about custom SAST rules?

A: They often treat rule creation as a one-time setup task. In reality, custom rules need ownership, version control, testing, and retirement, just like production code. Without that discipline, the rulebook turns into governance debt and the scanner gradually loses relevance as the codebase evolves.

Q: What should organisations check before giving a vendor access to source code?

A: They should review exactly which repositories, branches, tokens, and service accounts are required, then constrain the access to the minimum necessary for scanning. The security team should also verify offboarding, rotation, and logging so source code access does not persist after the tool is removed or replaced.

Technical breakdown

First and second generation SAST: what the tradeoff really means

First generation SAST tools typically lean on symbolic execution and flow analysis, which can produce deeper findings but often demand more tuning and more manual review. Second generation tools usually combine anti-pattern matching with flow analysis, which improves scale and developer usability at the cost of some depth. The practical difference is not abstract accuracy. It is whether your programme needs exhaustive review for a small number of applications or broad, repeatable scanning across many repositories with limited analyst time.

Practical implication: match the analysis model to release velocity, review capacity, and the amount of false-positive handling your teams can absorb.

Integration points, source code access, and identity controls

A SAST platform becomes part of the software delivery identity surface the moment it connects to source repositories, IDEs, CI systems, and cloud environments. Those integrations often require tokens, service accounts, or delegated repository access. That means the tool selection decision also affects secret handling, privilege scope, and lifecycle management. If access is broader than the tool actually needs, the AppSec control can become a new trust boundary rather than a risk reducer.

Practical implication: review the tool's access model as carefully as its findings model, especially where repository or pipeline credentials are involved.

Custom rules and homemade frameworks: how governance debt accumulates

Enterprises with bespoke frameworks, internal libraries, or non-standard code patterns often discover that default SAST rules cover only part of their real risk. Custom rule creation then becomes the difference between usable signal and generic output. This is where governance debt appears: teams must maintain detection logic alongside application change. The more unique the environment, the more important it becomes to test whether the platform supports rule authoring, versioning, and ownership.

Practical implication: validate rule customization early, or you will inherit a long-term maintenance burden that sits outside normal AppSec operations.

NHI Mgmt Group analysis

SAST selection is now a governance problem, not just a tooling problem. The article is really about alignment between analysis depth, developer workflow, and operational tolerance for friction. A tool that cannot fit the delivery model will be bypassed, no matter how strong its detection claims are. For security leaders, the selection question is whether the programme can absorb the operational cost of the control, not whether the control exists in theory.

Source code access creates an identity and secrets governance boundary. When a scanning platform needs repository access, IDE hooks, or CI connectivity, it becomes part of the trusted access chain. That makes service account scope, token handling, and offboarding part of AppSec procurement, which is where IAM and PAM teams should be involved from the start.

Custom rule maintenance is the hidden cost centre in SAST programmes. The article points to an issue many teams underestimate: out-of-the-box coverage rarely matches bespoke codebases. The result is either noisy output or a growing backlog of local rule exceptions and manual checks. Practitioners should treat rule ownership as a lifecycle obligation, not a one-time setup task.

Developer buy-in is the decisive adoption control. Proof of concept testing with real repositories, IDEs, and CI flows is the only reliable way to see whether the tool will be used. In mature programmes, adoption failure is a control failure because an unused scanner creates blind confidence rather than actual reduction in application risk.

AppSec tooling increasingly intersects with identity-governed delivery systems. Even when the topic is code analysis, the operational reality runs through source control, build credentials, and pipeline permissions. That means security architecture should evaluate SAST through both application risk and access governance, because the most dangerous gap may be the permissions required to run the control itself.

What this signals

SAST procurement is drifting toward a broader control conversation in which source-code access, pipeline credentials, and developer usability all matter at once. The programmes that succeed will treat scanner onboarding as part of identity and access governance, not as a standalone AppSec purchase. For teams that manage build systems and repository permissions, that means scrutinising who can see code, who can run scans, and how those permissions are revoked.

Developer-acceptance latency: this is the gap between a security control existing and engineers actually using it at speed. In AppSec, that latency shows up when tools slow releases, produce noisy results, or require too much manual tuning. The more a scanner depends on custom rules and ongoing exception management, the more it needs lifecycle ownership and review discipline.

As delivery environments become more automated, the same governance expectations that apply to NHIs begin to apply to the tools embedded in software pipelines. Access scope, secret handling, and offboarding are no longer only infrastructure concerns. They are part of the control plane that determines whether AppSec tooling reduces risk or quietly expands it.

For practitioners

• Map SAST access to least privilege Inventory every repository, IDE, CI, and cloud integration the tool requires, then reduce access to the smallest set of read-only permissions needed for scanning and reporting. Re-check tokens, service accounts, and offboarding procedures as part of procurement, not after deployment.
• Test language and framework coverage against real code Run the product against the actual languages, frameworks, and internal libraries used in production rather than a sample project. Include any homemade frameworks that force rule authoring so you can see where default detection stops and where local maintenance begins.
• Measure developer friction during proof of concept Evaluate false positives, review time, IDE performance, and CI latency with the engineers who will use the tool daily. If the scanner slows delivery or creates excessive manual validation, adoption will fall even if the detection quality looks strong in a demo.
• Define ownership for custom rules and exceptions Assign a named owner for every custom detection rule, suppression, and environment-specific exception so they do not become permanent unknowns. Treat those controls like production assets with versioning, review, and retirement dates.

Key takeaways

• Choosing a SAST tool is a governance decision because poor fit creates friction, blind spots, and weak adoption.
• Source-code access, repository tokens, and pipeline permissions make the tool selection process an identity control issue as well as an AppSec issue.
• The strongest selection criterion is not feature breadth but whether the tool can be used, maintained, and trusted in real developer workflows.

Key terms

• Static Application Security Testing: Static Application Security Testing is a method for finding security flaws by examining code, binaries, or configuration without executing the application. It is strongest when used early in development, where teams can fix issues before deployment and prevent avoidable defects from reaching production.
• First Generation SAST: First generation SAST usually relies on deeper program analysis such as symbolic execution and flow tracking. It can produce richer findings, but it often requires more tuning, more review time, and more operational maturity to keep signal usable at scale.
• Second Generation SAST: Second generation SAST commonly combines anti-pattern detection with flow analysis to produce faster, broader scanning across many projects. The tradeoff is that the control may miss some nuanced issues, so teams must understand where speed is replacing depth.
• Custom Detection: A custom detection is a rule written to identify a specific behaviour, pattern, or control violation that matters to one organisation. In browser security, it can target DOM activity, headers, or request flows so defenders can detect business-specific abuse instead of relying only on generic signatures.

What's in the full article

Semgrep's full article covers the operational detail this post intentionally leaves for the source:

• Comparative guidance on first generation versus second generation SAST selection for different engineering operating models
• Practical questions to ask vendors about IDE, CI, repository, and cloud integrations before rollout
• Advice on handling proprietary frameworks and writing custom rules for internal code patterns
• A proof-of-concept checklist for getting developers to test the tool before purchase

👉 Semgrep's full article covers the SAST selection checklist, integration questions, and proof-of-concept steps.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management for practitioners who need stronger control over access and lifecycle risk. It is a fit for teams that want identity discipline to extend into modern delivery and security operations.