Advanced appsec testing now hinges on automation and posture control

At a glance

What this is: This is a Veracode article arguing that application security testing has moved beyond baseline scanning toward automated remediation, posture management, and supply chain and cloud-native controls.

Why it matters: It matters to IAM and security practitioners because application security increasingly intersects with secrets, exposed credentials, CI/CD access, and the governance of identities embedded in delivery pipelines.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read Veracode's analysis of advanced features in application security testing software

Context

Application security testing is the set of controls used to find flaws in code, dependencies, containers, and delivery pipelines before those issues become exploitable. The governance problem is that traditional scanning can produce more findings than teams can act on, while modern development adds cloud-native complexity, third-party packages, and exposed secrets that widen the blast radius of every defect.

For identity and access governance, the interesting edge is not the scanner itself but the identities embedded in software delivery. Build systems, package registries, CI/CD automation, and deployment pipelines all rely on secrets, tokens, and service accounts. When those identities are poorly scoped or weakly monitored, AppSec becomes an identity control problem as much as a code-quality problem.

Key questions

Q: How should security teams prioritise application security findings in cloud environments?

A: Security teams should prioritise application findings by combining severity with exposure, reachability, ownership, and business impact. A medium issue on an internet-facing production service can be more urgent than a critical issue in dead code. ASPM helps by correlating scanner output with runtime context so remediation reflects actual risk.

Q: Why do exposed secrets in application pipelines create an identity governance problem?

A: Because a secret is an identity credential, not just a configuration value. If an API key, token, or certificate is embedded in code or CI/CD workflow files, it can be copied, reused, and abused outside its intended lifecycle. That makes ownership, rotation, revocation, and auditability identity controls, not just AppSec hygiene.

Q: What do security teams get wrong about software supply chain risk?

A: They often focus on known vulnerabilities inside dependencies and miss the trust path that delivers the software. Signed artifacts, build integrity, and separation of duties matter because attackers frequently abuse the pipeline rather than the package itself. Supply chain governance has to cover provenance, promotion, and update trust.

Q: How do organisations know if identity security posture management is working?

A: It is working if posture findings lead to measurable entitlement reduction, fewer stale accounts, and shorter remediation cycles. Dashboards alone are not enough. The signal is whether over-scoped access is being removed, reviewed, and tied back to accountable owners before it becomes an audit or breach issue.

Technical breakdown

Why basic SAST, DAST, and SCA leave a governance gap

SAST, DAST, and SCA each cover a different layer of exposure. SAST inspects code before execution, DAST probes a running application, and SCA inventories third-party components and known vulnerabilities. The limitation is not that these controls are obsolete, but that they are detection-first tools. They tell teams what exists, not which findings will actually be exploited, which dependencies are trusted, or which application paths carry the highest business impact. In modern pipelines, that prioritisation gap matters more than raw finding volume.

Practical implication: use baseline scanners as inputs to a risk triage model, not as the programme’s final decision point.

How ASPM changes application security posture management

Application security posture management, or ASPM, is an aggregation and governance layer that correlates findings across tools, policies, and environments. Instead of treating each scanner output separately, ASPM consolidates signals and ranks them by exploitability, exposure, and context. That is useful when the same application has code vulnerabilities, container misconfigurations, and exposed secrets spread across multiple pipelines. The technical value is not more detection. It is the ability to create a single operational view of application risk that supports policy enforcement and reporting.

Practical implication: establish one risk view for code, containers, and pipelines so remediation decisions are made consistently.

Why supply chain, container, and IaC controls now belong in AppSec

Modern applications are assembled from dependencies, container images, and infrastructure-as-code templates, so the attack surface now includes what is imported and deployed, not just what is written. Software supply chain controls aim to detect malicious or vulnerable packages before they enter the build. Container and IaC scanning extends that logic to runtime packaging and infrastructure definitions, where exposed secrets and misconfigurations can create immediate compromise paths. In practice, these controls help shift AppSec left without stopping at code analysis alone.

Practical implication: treat package intake, container build, and IaC review as part of the same control plane as source-code scanning.

NHI Mgmt Group analysis

Basic scanning is now a necessary but insufficient control. The article reflects a broader market reality: finding flaws is no longer the hard part, deciding what matters is. AppSec programmes that stop at SAST, DAST, and SCA often create alert saturation without reducing material risk. The governance lesson is that security value now comes from prioritisation, policy, and workflow integration, not from the volume of findings alone. Practitioners should treat scan output as evidence, not as decision-making.

Application security posture management is becoming the control layer above point tools. ASPM is best understood as a governance fabric that reconciles findings from code, runtime, and dependency controls into one operational picture. That matters because application risk rarely lives in a single layer anymore. The practical question is whether teams can connect technical findings to business context fast enough to drive action. Practitioners should expect posture management to sit between scanners and executive reporting.

Secret exposure debt: leaked credentials and tokens inside code and pipelines create remediation backlogs that outlast the exploit window. The source article touches exposed secrets in container and IaC workflows, and that is where AppSec starts to overlap directly with identity governance. Secrets are credentials, not simple configuration artefacts, and they should be treated as high-risk identities with lifecycle, rotation, and revocation requirements. Practitioners should connect AppSec findings to secret governance and service-account controls.

Software supply chain security is now an identity and trust problem, not only a code provenance problem. Package trust, dependency verification, and controlled package usage determine whether untrusted code can enter the build. Once a package is accepted, it inherits the trust boundary of the pipeline and can influence downstream applications, container images, and deployment artefacts. The policy question is whether teams can enforce trust at ingestion rather than detect compromise after the fact. Practitioners should align supply chain controls with pipeline identity and approval workflows.

What this signals

Secret exposure debt is becoming the most useful way to describe the gap between discovery and containment in modern software delivery. When leaked credentials persist for weeks, scanning alone cannot be the governance answer. Teams need ownership, expiry, and revocation workflows that connect application security to identity lifecycle control, and they should benchmark that against guidance such as the Ultimate Guide to NHIs , Key Challenges and Risks.

AppSec programmes now need to recognise that CI/CD identities behave like high-value non-human identities, especially when build systems can mint, store, and forward secrets across environments. That creates a direct policy link to least privilege, secret scope, and pipeline accountability. For teams formalising those controls, the 52 NHI breaches Report is a useful reference point for recurring failure patterns.

For practitioners

• Unify scan results into one prioritisation model Correlate SAST, DAST, SCA, container, and IaC findings so remediation is ranked by exploitability, internet exposure, and business criticality rather than by tool output order.
• Treat secrets found in code as identity incidents Route exposed API keys, tokens, and certificates into a revocation and rotation workflow that includes ownership, blast-radius assessment, and confirmation that the credential is no longer accepted by production systems.
• Add policy gates to package and image intake Block vulnerable or unapproved packages before they enter builds, and require verified provenance for container images and infrastructure templates used in release pipelines.
• Link AppSec findings to developer workflows Push remediation guidance into IDEs, pull requests, and ticketing systems so developers can resolve issues without leaving the delivery path, while security keeps policy authority.

Key takeaways

• Basic application security testing still matters, but it is no longer enough when code, dependencies, containers, and pipelines all create separate risk surfaces.
• The practical bottleneck is prioritisation and remediation, especially when exposed secrets and supply chain issues turn technical findings into identity and trust problems.
• Teams that connect scanners, posture management, and pipeline controls will reduce noise and improve governance without relying on more manual review.

Key terms

• Identity Security Posture Management: Identity security posture management is the continuous assessment of identity configuration, privilege, and exposure across an environment. It focuses on drift, overprivilege, and control gaps so teams can see where IAM, PAM, and NHI governance are failing before those gaps become incidents.
• Software Supply Chain: A software supply chain is the set of tools, identities, dependencies, and processes that turn source code into deployed software. Because it relies on automation and privileged machine identities, it becomes a governance problem when access, signing, and deployment controls are too broad.
• Secrets Exposure: Secrets exposure is the accidental or uncontrolled disclosure of credentials such as API keys, tokens, certificates, and service passwords. In NHI programs, it matters because a leaked secret often behaves like a live identity, creating immediate access risk until it is revoked or rotated.
• Infrastructure As Code Secrets Security: Infrastructure as Code secrets security is the practice of keeping credentials out of code while controlling how they are issued, used, and revoked in automated delivery. It combines repository hygiene, pipeline governance, logging, and lifecycle management so secrets do not become durable artefacts.

What's in the full article

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

• How the vendor maps advanced AppSec capabilities to each stage of the development lifecycle
• Specific examples of AI-driven remediation, ASPM, and supply chain controls in workflow
• The Gartner Magic Quadrant context used to frame the market view
• How the vendor positions container and IaC scanning within a broader AppSec programme

👉 Veracode's full article covers the AppSec capability set, workflow integration, and market framing in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle basics. It gives practitioners a common control language for securing identities that software delivery depends on.