Notifications
Clear all
Topic starter
25/06/2026 5:10 pm
TL;DR: Most AppSec programs fail when they optimize dashboards instead of developer velocity, according to Akeyless, then describes an AI-driven control layer that starts in the IDE, gates only newly introduced risk in pull requests, and automates remediation without bypassing review. The key shift is from noisy detection to context-aware enforcement that preserves flow while tightening control.
NHIMG editorial — based on content published by Akeyless: AI-native AppSec shifts from dashboards to developer velocity
Questions worth separating out
Q: How should security teams reduce AppSec noise without weakening control?
A: Start by gating only newly introduced risk and moving low-friction checks earlier in the developer workflow.
Q: When does shift-left security become counterproductive?
A: It becomes counterproductive when every control behaves like a hard stop for every repository condition, including legacy findings the current change did not create.
Q: How do you know if change-based AppSec gating is working?
A: Look for fewer false failures, faster merges for unchanged code, and a higher ratio of blocked findings that are actually linked to the current change.
Practitioner guidance
- Map security controls to the developer workflow Place lightweight checks in the authoring layer for secrets, risky patterns, and unverified dependencies so obvious issues are caught before a pull request exists.
- Separate inherited debt from new risk Configure pull request gates to fail only on newly introduced high or critical findings, while tracking existing issues in a separate remediation path.
- Preserve human approval for remediation Allow automated fix generation, but require explicit review and approval before changes are merged or deployed into production.
What's in the full article
Akeyless's full article covers the operational detail this post intentionally leaves for the source:
- How the IDE-time guardrails are configured to flag insecure code patterns and unverified packages.
- The validation logic behind delta gating across logic, supply chain, environment, and provenance checks.
- Examples of AI-generated remediation flows for dependency upgrades and hardened configuration files.
- The internal control boundaries that keep agents from bypassing human review.
👉 Read Akeyless's analysis of AI-native AppSec and developer velocity →
AI-native AppSec and developer velocity: what changes for teams?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
25/06/2026 5:41 pm
Dashboard-first AppSec creates an attention problem before it creates a control problem. When security teams measure success by alert volume, they often optimise for visibility instead of risk reduction. That pattern pushes developers to treat AppSec as overhead, which lowers compliance and increases workarounds. The field should stop confusing more findings with better governance.
A few things that frame the scale:
- Companies are dedicating an average of 32.4% of their security budgets to secrets management and code security, with US organisations leading at 40.8%, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, which helps explain why workflow-native controls matter.
A question worth separating out:
Q: What should teams do when AI tools propose security fixes?
A: Require every generated fix to remain reviewable, traceable, and tied to the original finding. AI can accelerate remediation, but it should not erase the approval boundary or hide the reasoning behind a code change. The goal is faster correction, not autonomous release authority.
👉 Read our full editorial: AI-native AppSec shifts from dashboards to developer velocity
