Notifications
Clear all
Topic starter
02/08/2026 12:21 pm
TL;DR: Cloud-native development, open-source dependencies, and AI-generated code are widening the application security attack surface, while end-of-cycle scans and fragmented workflows fail to keep pace, according to Veracode. The practical shift is toward secure SDLC controls, package screening, dependency visibility, and developer-first enforcement that reduce risk without slowing delivery.
NHIMG editorial — based on content published by Veracode: Navigating the Fog: A Guide to Application Security in the Cloud
Questions worth separating out
Q: How should security teams implement secure SDLC controls across modern delivery pipelines?
A: Start by defining security requirements at design time, then enforce code scanning, dependency review, and verification before release.
Q: Why do malicious packages keep bypassing software supply chain controls?
A: They bypass controls because build systems often trust registry names, default resolution paths, and automation permissions more than they trust human review.
Q: What breaks when dependency visibility is missing in application security programmes?
A: Teams lose prioritisation, because findings from code, containers, and open-source libraries cannot be correlated into one risk picture.
Practitioner guidance
- Build a single cloud AppSec policy layer Unify SAST, SCA, DAST, container scanning, and IaC checks into one prioritisation workflow so teams can see which issues are actually exploitable and who owns them.
- Block risky packages before resolution Use package firewall rules, namespace protections, and provenance checks to stop typosquatting, dependency confusion, and hijacked packages from entering the build system.
- Treat pipeline credentials as governed non-human identities Inventory secrets, tokens, and service accounts used in CI/CD, then tie each one to ownership, rotation, and exception expiry so build access is not permanent by default.
What's in the full article
Veracode's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step guidance on building a secure SDLC across IDE, CI/CD, staging, and production.
- Operational examples of package firewall policy, exception workflows, and policy-as-code enforcement.
- Practical details on SBOM generation, compliance reporting, and developer-first remediation flows.
- A worked view of how to combine SCA, SAST, DAST, and governance dashboards in one programme.
👉 Read Veracode's guide to application security in the cloud →
Cloud AppSec in 2025: are your controls keeping up?
Explore further
02/08/2026 1:21 pm
Cloud appsec has become a governance problem, not a tooling problem. Fragmented scanners can produce more findings without improving control, because the organisation still lacks a single policy model across code, dependencies, containers, and runtime. That makes prioritisation the real control gap. NIST CSF and CIS Controls both point toward coordinated protection, not isolated checks. Practitioners should treat unified risk governance as the primary design requirement, not an optional reporting layer.
A question worth separating out:
Q: Who is accountable when cloud AppSec controls fail in the SDLC?
A: Accountability should sit with the teams that own the pipeline policy, not only with the security scanner. When secrets, build permissions, and package trust are embedded in delivery, ownership has to include engineering, platform, and security leadership.
👉 Read our full editorial: Application security in the cloud needs a unified SDLC model
