Notifications
Clear all
Topic starter
12/06/2026 12:28 am
TL;DR: Cloud security and AppSec are still often run as separate disciplines, creating blind spots, duplicate tooling, and slower remediation as environments expand across cloud and CI/CD, according to Orca Security’s Cloud Security Live session with Snyk. Breaking those silos matters because unified context is now a prerequisite for scalable identity, configuration, and workload protection.
NHIMG editorial — based on content published by Orca Security: Cloud Security Live takeaways on unifying cloud security and AppSec
Questions worth separating out
Q: How should security teams unify cloud security and AppSec without slowing delivery?
A: Start by connecting findings across source code, build artefacts, and runtime assets so teams share one risk picture.
Q: Why do separate cloud and AppSec tools create governance risk?
A: Separate tools fragment evidence.
Q: When should organisations prioritise unified visibility over more point tools?
A: When cloud environments are multi-cloud, containerised, or moving quickly through CI/CD, unified visibility should come first.
Practitioner guidance
- Create a single risk trace across code and cloud runtime Map each finding from source repository to image, container, and deployed workload so ownership and exposure are visible in one path.
- Move scanning into developer workflows Run SAST, SCA, and IaC checks in the IDE and CI/CD pipeline so issues surface before deployment.
- Assign one accountable owner for cross-domain findings Define who closes the loop when a cloud control issue is rooted in application code or a dependency.
What's in the full article
Orca Security's full article covers the operational detail this post intentionally leaves for the source:
- Session-specific commentary from Orca and Snyk on how cloud security and AppSec teams can work from a shared operating model.
- Practical examples of how to connect pre-deployment scanning to runtime cloud risk without creating duplicate review queues.
- Guidance on how developers can receive security feedback in workflow rather than through separate escalation channels.
- The event framing and speaker context from Cloud Security Live, including the original discussion setup.
👉 Read Orca Security's Cloud Security Live take on unifying cloud security and AppSec →
Cloud and app security silos: what IAM teams are missing?
Explore further
12/06/2026 9:43 am
Cloud and AppSec silos create an identity governance gap, not just a tooling gap. The real problem is that access, workload, and code evidence are being reviewed in different systems with different owners. That means nobody can reliably answer who is accountable for a risky runtime path when the deployed asset and the vulnerable component live in separate operational domains. Practitioners should treat cross-domain correlation as an identity control requirement, not an optional reporting feature.
A few things that frame the scale:
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
- 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to the 2026 Infrastructure Identity Survey.
A question worth separating out:
Q: What is the difference between runtime cloud security and AppSec in practice?
A: AppSec focuses on code, dependencies, and build-time weakness. Runtime cloud security focuses on the deployed workload, configuration, and access state. They become operationally different only when teams fail to connect them, because the same weakness can look like a code issue, a cloud issue, or both.
👉 Read our full editorial: Cloud and app security silos are widening cloud risk
