Cloud & Supply Chain Security: A Tool Stack That Actually Works

Editorial Note: This article presents an analytical framework for evaluating cloud security and software supply-chain tools. Its scenarios are illustrative composites, not accounts of specific organizations or verified incident reports. Tool capabilities and implementation outcomes depend on the environment, configuration, and operational context.

Cloud Security and Supply Chain Security: A Truly Operational Toolstack

Opening: All the tools are green, yet the data is still missing.

When PagerDuty rings, every security dashboard at Vantor Labs is green.

This was the kind of alert Daniel Reyes, on late‑night duty, least wanted to see: Wiz hadn’t flagged any new attack paths, and Prisma Cloud’s compliance dashboard sat quietly at a score worthy of a weekly report. Lacework had not yet been deployed to the affected workloads, so it provided no behavioral monitoring for the incident. The alert came from the cloud provider itself—abnormal billing activity: an IAM credential had pulled object storage traffic in a short span that far exceeded its usual volume.

The investigation over the next few hours exposed a critical vulnerability in the security architecture Daniel had built over the past two years. The nature of that vulnerability warrants close scrutiny by anyone working on the front lines of cloud and supply-chain security: the problem has never been a lack of tools. Vantor Labs boasts a generous security budget compared to its peers—Wiz, Prisma Cloud, Snyk, and Trivy have all been purchased, deployed, and are actively in use.

This article tackles exactly this kind of issue. It begins with two composite scenarios grounded in recurring cloud security and software supply-chain risk patterns—one in which an incident has occurred, and another in which a team is on the verge of being overwhelmed by alerts. It then examines an eight-tool cloud security and supply-chain security stack, clarifying where each tool fits and where its responsibilities end. Finally, it explores a development that is reshaping how work is done at this level: what generative AI can—and cannot—do within this framework, along with a red line that must never be crossed.

Scene One: When every tool is green and the data is still gone

Vantor Labs is a mid-sized B2B SaaS company whose customers are primarily medium-sized enterprises in Europe and North America. The platform engineering team comprises about twenty members, while the security team consists of four people, including Daniel. Jonas is the fastest‑moving engineer on the platform team, which has sown a very common source of risk.

While troubleshooting a sporadic production‑environment issue, Jonas temporarily hard‑coded a set of cloud credentials into his CI script to enable the pipeline to directly call the diagnostic API. Once the problem was resolved, he forgot to revert the change. Later, during a code refactoring, that snippet was deleted—but the credentials remained in the Git history. Incidents like this happen every day across countless repositories worldwide. Scanning tools such as Gitleaks could catch them if hooked into pre‑commit hooks, but Vantor Labs’ secret scanner is only configured for CI pipelines, and at the time of that branch merge, a scan was inadvertently skipped.

After obtaining the credentials, the attacker’s subsequent actions were far from sophisticated; yet each step precisely exploited a vulnerability in Vantor’s security architecture.

Step one: Use the credential to query account information. The IAM role associated with this credential has far more permissions than actually needed—it inherits a “Platform Team General” role that can read most buckets and also initiate changes to several production clusters. All permission‑audit tools are aware of this: PMapper has run checks, and Wiz’s permission map likewise flags this role as over‑privileged. Yet such findings about excessive permissions are categorized as “housekeeping issues,” relegated to lower priority behind a host of high‑CVSS‑score vulnerabilities. A remediation ticket has been open for three months, yet no one has taken action.

Step two: locate a compute instance running an image built a quarter ago. The web framework in that image has a remote code execution vulnerability that has been publicly known for quite some time. Snyk had already flagged it, and the scan results were sitting in the console’s list, somewhere in the middle of a long “to be fixed” queue. Trivy had also reported it—during the build‑time admission process, this vulnerability was configured to trigger a warning rather than a failure, because at the time, the guidance was: “Fixing it carries risks; let’s monitor the situation first.”

Step three: horizontally scale out from this instance to the storage bucket and begin pulling data. Throughout the process, CloudTrail faithfully logged every API call; however, the alert rule’s threshold for “short‑term high‑volume reads” was based on the normal peak of batch analytics jobs—significantly lower than the rate observed during this breach. Lacework has not yet been deployed to these workloads, with the project scheduled for the next quarter.

After the data was exfiltrated, the cloud provider’s anomaly alert brought it to a close.

The post‑incident review meeting was rather unproductive, but the conclusions were intriguing: no single tool had failed in its duty. Snyk had flagged that vulnerability, providing complete details on the timing, version, and remediation recommendations; Wiz had mapped out the attack path—exposed entry points, over‑privileged roles, vulnerable container images, and a bucket storing customer data—clearly linking all four stages, even ranking it among the top entries in the attack‑path list; and Prisma Cloud’s policies had also detected the instance’s outdated image. Three separate alerts lay dormant across three distinct consoles, each using a different severity scale and directed to three different teams. Yet at no point did anyone receive an alert that warranted immediate action.

The attacker did not defeat any of the tools. The attacker simply slipped through the gaps between them.

Scene Two: A Tuesday Overwhelmed by Eight Hundred Alerts (Vulnerability Alert Fatigue)

Meridian Freight is a software company specializing in international freight, with a five-person security operations team. The team leader is Priya Nair, and her team has performed well this year—implementing Snyk, Semgrep, Trivy, and Dependency-Track into their toolchain, running Prisma Cloud in the cloud, and having all the essential components in place.

On an ordinary weekday morning, Priya opened the duty‑desk dashboard, and the numbers were just over 800: Snyk had flagged more than 300 dependency vulnerabilities, Trivy had reported over 150 image‑related issues in the nightly build, Prisma had piled up two hundred compliance‑violation emails, and Semgrep had lit up several merge requests. Meanwhile, Dependency‑Track was quietly sending notifications— a newly disclosed CVE had hit a string of projects listed in the company’s SBOM.

The team’s on‑call engineer spent the entire morning addressing the top‑priority issue: a dependency vulnerability with a CVSS score of 9.8. The process—upgrading, regression testing, and releasing—was executed in full compliance with standard procedures. In the afternoon, during validation, the engineer casually searched the codebase for the package’s call sites—but found none. Digging deeper, it turned out that this dependency had been introduced as an indirect transitive dependency, and the corresponding code path was never even enabled in the production build.

A vulnerability rated 9.8 in severity can require a full morning of effort and an entire regression testing cycle to fix, even when the affected dependency is not used by the relevant production code path. In this case, the immediate exploitability may be much lower than the severity score suggests—but that conclusion still requires validation of the dependency's actual reachability and deployment context.

That same afternoon, tucked away on page 47 of the alert list, lay a vulnerability rated only slightly above average. Its payload was being invoked directly by production‑level business code, the microservice hosting it sat behind a public‑facing gateway, and exploit code for this CVE had already surfaced in open‑source channels—and even made its way into CISA’s KEV catalog. Yet no system had connected these three dots: call‑path accessibility embedded in the code, public exposure configured in the cloud, and KEV status tracked in threat intelligence.

This vulnerability remained in the queue for another two weeks before it was discovered. The team had already put in a great deal of effort; the real gap lay in the fact that no layer of the system was responsible for answering that crucial question: Is this alert worth acting on tonight?

Later, at the team’s retrospective, Priya said something very insightful: “What we’re lacking isn’t scanning capability—it’s a referee.”

A Map: Four Tiers, Eight Tools, One Pipeline (Building the stack: DevSecOps toolchain architecture)

If you break down the first two scenarios, you’ll see that they point to the same underlying structural issue: the right tool was chosen, but the wrong position was selected. In this section, we’ll start by laying out the entire picture.

A complete cloud security and supply chain security stack can be divided into four layers based on the direction of code flow:

At the code level—Semgrep and Snyk. Semgrep focuses on the code written by the team itself: injection, deserialization, risky function calls, and internal coding standards. Snyk, on the other hand, examines the code that the team depends on: vulnerabilities in third-party dependencies, their maintenance status, and license compliance. While both address “code security,” they target entirely different types of risks and cannot substitute for one another.

Build and Artifact Layer — Trivy (or Grype) and Dependency-Track. Trivy scans the resulting container images, covering everything from OS packages to language dependencies, and can also examine IaC files and leaked secrets. It’s fast enough to be integrated into every build. Dependency-Track deserves a separate explanation: it doesn’t perform scanning itself; rather, it serves as a consumer of SBOMs (Software Bill of Materials). In CI workflows, Syft generates CycloneDX‑formatted SBOMs and feeds them to Dependency-Track, which continuously monitors each component in the manifest—just because there are no vulnerabilities today doesn’t mean there won’t be one in thirty days. As soon as a new CVE is disclosed, Dependency-Track automatically cross-references it, identifies affected projects, and notifies the responsible parties through configured channels.

Cloud Configuration and Risk Context Layer — Wiz or Prisma Cloud. This layer helps teams understand their cloud assets, exposed attack surfaces, identity permissions, and relationships between vulnerabilities and sensitive resources. Both platforms offer broad cloud security capabilities, but their coverage, integrations, enforcement options, and operational fit differ. For many teams, selecting one primary platform can reduce operational overlap; using both should be justified by a specific coverage gap, integration requirement, or independently valuable control.

Workload and Runtime Layer — Aqua and Lacework. Aqua enforces strict control: only the components declared in the container image are allowed to run, and any deviation is blocked. Lacework focuses on monitoring: it establishes a behavioral baseline for workloads, and any deviations from this baseline are flagged for forensic analysis and alerting.

Let’s first dispel a common misconception: Wiz, Prisma Cloud, Aqua, and Lacework are often grouped together in “cloud security tool” comparisons, even though their capabilities and primary strengths differ. CNAPP (Cloud-Native Application Protection Platform) brings together multiple cloud security capabilities; CWPP (Cloud Workload Protection Platform) focuses on protecting workloads, including runtime threats; and behavioral analytics helps identify suspicious deviations over time. These are overlapping capability areas, not mutually exclusive product categories. Comparing them as direct competitors is like asking whether a map, a burglar‑proof door, and a surveillance camera are all equally secure—there’s something fundamentally flawed about the premise itself.

On the cloud side: CNAPP is a visibility tool, not a defense perimeter (Wiz vs Prisma Cloud vs Aqua vs Lacework)

When you lay out the real differences among the four tools, the selection logic becomes much clearer.

The strength of Wiz lies in its ability to correlate data. It consolidates cloud configurations, IAM permissions, network exposure surfaces, and workload vulnerabilities into a single dashboard, visually mapping out attack paths—from public-facing entry points, through over‑privileged roles, to vulnerable container images, and finally to sensitive data stores. The very path Daniel reviewed after the incident was already mapped out by Wiz beforehand—this is precisely what makes Wiz’s product offering so compelling. Its limitations are equally clear: deep runtime enforcement for containers isn’t its core competency, and relying on Wiz as a workload‑level defense is misaligned with its intended use case.

The strength of Prisma Cloud lies in the breadth of its cloud security capabilities, which can support organizations with diverse infrastructure and compliance requirements. However, evaluating a platform with multiple modules can be complex, and the total cost depends on the capabilities purchased and deployed. Teams should identify the features they actually need, confirm the commercial scope, and establish ownership for configuring and maintaining them. A broad feature set creates value only when the relevant controls are enabled and used.

The strength of Aqua lies in its robust enforcement at the container runtime level. Its enforcer provides process‑level control, with drift prevention being one of its most cost‑effective features: once a container is launched, any executable that isn’t part of the original image is blocked from running. Cryptomining malware, reverse shells, and post-exploitation tools are common examples of activity that runtime controls may help detect or prevent when they introduce unauthorized processes. With drift prevention correctly configured and enforced, Aqua can block execution that violates the applicable runtime policy. However, the effectiveness of this control depends on the policy and deployment context; it does not eliminate every attack that can occur within a container. A common reality in the industry is that many teams purchase Aqua, yet keep drift prevention disabled. Having it installed but never activated renders the solution essentially useless.

The strength of Lacework lies in its behavioral baselining. It leverages UEBA principles to model cloud workloads, continuously learning what normal behavior looks like for each service and issuing alerts when deviations occur. Its behavioral analytics and investigation capabilities can help teams identify suspicious activity and investigate incidents. However, detection quality and false-positive rates depend on the environment, available telemetry, and tuning. Its behavioral monitoring capabilities should be evaluated separately from the configuration and attack-path analysis provided by cloud security posture tools. Incidentally, Lacework has now been integrated into Fortinet, so it’s worth factoring product roadmap stability into your purchasing decision.

If all four tools are deployed, the overlap quickly becomes a governance challenge: each tool scans configurations, reports vulnerabilities, and assigns severity ratings, leaving frontline operations overwhelmed by three competing sets of standards. A viable division of labor is to designate a single arbiter for each type of signal. Configuration and attack‑path analysis should be handled by Wiz (or Prisma), with Aqua focusing solely on runtime blocking without duplicating reporting, and Lacework providing behavioral alerts while refraining from reviewing configurations. Overlap isn’t wasteful; redundant alerts are.

Here’s another self‑assessment technique that deserves special mention. At regular intervals, pull up the list of attack paths generated by Wiz and review it item by item: for each node along every path, compare it against your toolchain and ask, “Who should have blocked this step, and why didn’t they?” If the first step in the path is an exposed bucket, it means the configuration policy wasn’t set to block; if a known‑vulnerable image appears in the middle, it indicates Trivy’s enforcement was downgraded to warning or someone performed a force merge; and if an abnormal process behavior occurs near the endpoint, it suggests Aqua was installed but not configured to run in block mode. Each attack path serves as evidence of a specific failure somewhere in your toolchain. This exercise is more valuable than holding ten security weekly meetings, because it translates the abstract notion of “system health” into a checklist you can tick off one item at a time.

On the supply chain side: an SBOM is either a living ledger or a dead PDF (Software supply chain security and SBOM management)

At the end of 2021, the Log4Shell vulnerability delivered a stark lesson to the entire industry: when it came to disclosing vulnerabilities, most organizations couldn’t even answer the question of “where exactly they were using this component.” Several years later, while the toolchain has matured considerably, many teams’ SBOM practices still remain at the stage of “complying with audit requirements by filing a record”—simply generating a list, saving it as a file, and calling it a day.

This kind of SBOM is dead. It captures the components at a single point in time during a build and becomes outdated the moment it’s written to disk. To bring it to life, you need a system that continuously consumes it—and that’s precisely where Dependency‑Track fits in this stack: CI pipelines use Syft to generate CycloneDX‑formatted SBOMs with each build and push them to Dependency‑Track, which then continuously cross‑checks against public vulnerability databases, automatically identifying affected projects whenever a new CVE is disclosed. Going a step further, it tags each project with its business system and responsible owner, routing notifications directly to the right person—without such routing, Dependency‑Track would simply become another forgotten vulnerability database. When a Log4Shell‑level vulnerability strikes again, the entire incident response can be streamlined into two steps: first, search for the component name in Dependency‑Track to obtain a list of affected systems and their owners; then, verify the actual exposure status of those instances. Providing a clear “affected,” “not affected,” or “pending” classification within four hours is what sets a living inventory apart from a static PDF.

There are also common mismatches in the combination of code and dependencies. Two typical misconceptions are:

Misconception 1: Snyk and Trivy are redundant—just use one. Snyk and Trivy overlap in several vulnerability-scanning use cases, including container image and dependency analysis, but the extent of that overlap depends on the targets, configurations, and workflows being compared. Their practical differences are easier to evaluate by looking at developer experience, scan coverage, CI integration, policy enforcement, and operational cost. Use Snyk during the development phase: its IDE plugin and remediation recommendations deliver a strong developer experience, encouraging adoption—after all, the biggest obstacle for security tools in development is developers simply bypassing them. For CI/CD gatekeeping, Trivy can be a cost-conscious option: it is open source and supports scanning for vulnerabilities, misconfigurations, and secrets across relevant targets. Teams should still validate its coverage and enforcement behavior against their own build pipeline, configure the required scanners and exit conditions, and account for maintenance and integration costs. One ensures a great developer experience; the other provides robust enforcement.

Misconception #2: Semgrep scans the code, so dependency scanning is just icing on the cake. Semgrep detects logical vulnerabilities in proprietary code, while Snyk and Trivy identify known flaws in third-party dependencies. These two categories of vulnerabilities hardly overlap—“what was written” and “what was referenced” represent two distinct dimensions of supply-chain security. What’s often underestimated—and truly worth investing in—is Semgrep’s ability to define custom rules. Turning an organization’s internal coding standards into Semgrep rules—such as prohibiting the use of a custom encryption/decryption function or mandating parameterized queries in ORM—is something commercial SAST tools struggle to achieve at low cost.

Going one layer deeper, we arrive at the issue of provenance and artifact integrity. An SBOM records the software components included in an artifact, while a digital signature can help verify the artifact's integrity and the identity associated with its signing process. Sigstore's Cosign supports artifact signing and verification, while the SLSA framework provides guidance for strengthening build integrity and provenance. These controls address different but complementary risks, including unauthorized artifact substitution and compromised build processes. An SBOM helps establish what is present; signing and provenance controls help establish where an artifact came from and how it was produced. Neither replaces the other, and neither alone guarantees that an artifact is free of vulnerabilities or compromise.

Arrangement: One judge per layer, twenty alerts per day (Pipeline gating and alert triage strategy)

The map is complete—back to that Tuesday with Priya. No on‑call human can make the right call at a pace of 800 alerts per day; piling more people onto the problem won’t solve it. There’s only one viable path: orchestration—assigning just one “referee” at each layer of the pipeline to decide which alerts to block, thereby reducing the number of alerts entering the on‑call queue to a level a single on‑call engineer can handle.

A practical hierarchical trigger structure should assign one primary decision-maker for each enforcement stage, while allowing supporting tools to contribute evidence:

Code review: Semgrep provides code-level findings, with one designated policy determining which findings block a merge.
Dependency and artifact review: Snyk and Trivy can contribute vulnerability findings, but a single CI policy should determine whether a build is blocked.
Cloud configuration and attack paths: Wiz or Prisma Cloud provides cloud-risk context, with explicit ownership and remediation rules for high-priority findings.
Runtime detection and response: Aqua, Lacework, or another runtime monitoring solution supplies runtime evidence, with defined escalation criteria and a human-led incident response process.

The critical principle is that overlapping tools should not independently impose conflicting enforcement rules at the same stage. A single decision policy should govern each gate, even when several tools contribute findings. This reduces inconsistent decisions and makes exceptions easier to track.

The second knob is baseline filtering. The era of pushing every single alert to everyone needs to end. Two public data sources provide ready‑made filtering layers: EPSS, maintained by FIRST (which offers exploitability prediction scores, answering “how likely is this vulnerability to be actively exploited?”), and CISA’s KEV catalog (Known Exploited Vulnerabilities, which tells us “has this vulnerability been confirmed to be exploited in the wild?”). A practical initial configuration is to use KEV status and EPSS scores as prioritization signals for the on-call queue, alongside asset criticality, public exposure, exploitability in the deployed environment, and known attack paths. Vulnerabilities that do not meet the initial escalation criteria can be routed to a scheduled review queue, provided that exceptions and escalation paths remain in place for high-impact assets or newly discovered evidence of active exploitation. In this illustrative scenario, Priya’s team uses the rule to reduce the daily alert volume reaching the on-call dashboard from roughly 800 to just over 20. The intended outcome is not simply fewer alerts, but a smaller queue of findings that on-call engineers can review properly. In a real deployment, the reduction would need to be measured alongside missed high-risk findings and escalation accuracy.

The third knob is the learning period. After deploying behavioral detection tools, teams can consider an initial observation period in which alerts are monitored and tuned before enforcement or broad escalation is enabled. The duration should reflect workload variability, deployment cycles, and the product's baseline-learning behavior. Where feasible, known high-risk detections and critical alerts should remain active during this period. If alerts are triggered before the baseline has been fully learned, the result is a page‑full of “new service launch”‑style noise, which the team quickly learns to ignore on the console.

The final piece of the puzzle lies outside the code: in supply chain governance, a significant portion revolves around processes, not tools. Before introducing a new open-source component, running it through an admission checklist—assessing its level of active maintenance, its license, and any past incidents—can keep a substantial amount of risk out of the SBOM. This checklist doesn’t need to be elaborate; three or five quick checks suffice. The key is having such a gate, one that no one can bypass.

Subtraction under budget constraints (Cloud security tools for mid-size teams)

This section is intended for those who will be presenting the above‑mentioned framework to secure the budget, and it’s also meant for companies with security teams of only two or three people.

If your budget only allows for one tool on the cloud side, choose Wiz. The reason is straightforward: it delivers results fastest. Its agentless assessment capabilities can help teams gain visibility into cloud assets and potential attack paths without requiring an agent on every workload. The speed and completeness of that initial view depend on cloud permissions, integrations, asset coverage, and the configuration of the environment. For a team eager to answer the question, “Where do we stand right now?”, this speed advantage is decisive.

Aqua and Lacework can be largely replaced by open source solutions: Falco provides runtime behavior monitoring, covering much of Lacework’s functionality—at the cost of having to write your own rules and handle alerts yourself. Combining Wiz or Prisma Cloud with Falco and a suitable set of open-source dependency and artifact management tools can provide meaningful coverage for many common cloud and software supply-chain security needs. The actual coverage depends on the organization's threat model, compliance requirements, runtime environment, and willingness to maintain and tune the open-source components.

There’s a counterintuitive observation: the most expensive stack often hides a subtle flaw—each tool is only used at 20% of its capacity. Prisma bought the full CNAPP suite but only activated configuration scanning; Aqua deployed drift prevention without enabling it; Dependency-Track integrated SBOMs but failed to configure notification routing. Such waste isn’t visible on the procurement list, yet it becomes glaringly apparent when mapping out attack paths. The right question to ask before purchasing isn’t “Is this tool good?” but rather, “At what layer does it sit in our security stack, and who currently serves as the gatekeeper?”

AI in this layer: Triage, not replacement (AI in security operations: triage, policy-as-code, and where it breaks)

Once the toolchain is in place, there remain gaps between various tools—gaps that happen to be precisely where generative AI can deliver the greatest value. This layer of work shares a common characteristic: it is text‑intensive, involves cross‑system integration, and relies on knowledge‑based reasoning—exactly the kinds of inputs that language models excel at handling. All the use cases below rest on two shared prerequisites: the data fed into the model must remain within the enterprise’s controlled domain (under an enterprise‑grade agreement or via private deployment), and any production output must undergo dual validation—by humans and in a testing environment.

First: Cross-platform alert aggregation and threat analysis, with the potential to reduce the cost of incident triage. The biggest daily pain point in the toolchain is siloed operations—Snyk reports CVEs, Wiz maps attack paths, and Lacework flags behavioral anomalies. On-duty analysts have to switch back and forth among separate consoles, piecing together fragmented data into a coherent conclusion. By consolidating API outputs from each platform and feeding them into a model, teams can generate unified, standardized analysis cards: for example, whether a dependency vulnerability reported by Snyk resides on a node along a specific Wiz attack path, whether the associated workload has recently exhibited abnormal behavior, and whether the available evidence supports urgent remediation or scheduled review. This approach can reduce manual information gathering and help standardize initial triage. The actual time savings and analysis quality depend on data coverage, integration quality, validation requirements, and the complexity of each incident; any quantified improvement should be established through a controlled evaluation.

Item 2: SOP for Intelligence Analysis During Vulnerability Incidents. In the critical first few hours after a new vulnerability is disclosed, analysts follow a highly standardized workflow: verifying the list of affected components using Dependency-Track data, reviewing the vulnerability description and public discussions, assessing whether the triggering conditions and exploit code have been made public, cross-referencing the KEV status, and issuing prioritization recommendations. An AI model can help summarize evidence, draft investigation notes, and organize preliminary recommendations, but analysts still need to verify the affected components, source reliability, exploitability, and operational context before reaching a decision. A mature team can formalize repeatable parts of this workflow into templates and prompts, reducing repetitive drafting while retaining human responsibility for validation and approval.

Third: The productivity of “code as strategy.” Two proven use cases: feeding the model examples of code smells and their fixes to generate Semgrep rules—early versions achieved a very high pass rate, with humans only making minor adjustments; and describing enterprise cloud security baselines to the model to generate corresponding custom detection logic (Prisma’s RQL, Checkov rules, or OPA’s Rego). In the past, “inability to write good rules” was a major bottleneck for many teams’ customization capabilities; that ceiling has now been significantly raised.

Fourth: Initial screening of runtime alerts. Alerts from Aqua and Lacework are riddled with a large amount of “noise that looks like an attack but is actually a routine inspection.” By having the model assist with initial filtering based on process trees, image sources, and the historical records of scheduled tasks, teams can prioritize cases that appear suspicious and align with known attack techniques for human review. This approach may reduce the time spent handling low-value alerts, but the actual reduction depends on the quality of the underlying telemetry, the filtering criteria, and the rate of missed or incorrectly classified alerts. The goal is to reduce unnecessary work without allowing potentially serious incidents to disappear from the review process.

Fifth, and perhaps the most easily overlooked: reverse validation. When a security team uses AI to write code themselves, they must ensure that the AI-generated code unconditionally passes through all existing access controls—without exception, including Semgrep, Snyk, and Trivy. The reason is straightforward: models may suggest package names that do not exist or that they have not verified. Attackers can exploit this behavior by registering plausible package names that developers may mistakenly trust and install, a risk often discussed in the context of AI-assisted coding and software supply-chain attacks. AI-generated dependencies should therefore be verified against trusted package registries and subjected to the same dependency and security controls as other software. This represents supply-chain security’s reflexive check of its own workflows; the established dependency‑based access controls happen to provide an effective line of defense.

There are three red lines: asset and vulnerability data must be handled within the organization’s approved security and data-governance boundaries; AI-generated output intended for production must undergo human review and appropriate testing; and AI-generated permission policies—especially IAM policies—must be manually reviewed and fully understood before deployment. If a team cannot comprehend the permission policies it is operating with, those policies themselves constitute an attack surface, regardless of whether they were authored by humans or by a model.

Conclusion: Back to Those Two Teams

The first thing Vantor Labs did after the incident wasn’t to buy new tools. Daniel’s team systematically mapped out every existing attack path in Wiz, tracing each one backward through its nodes to identify “which link should have stopped it and who is now responsible for that part,” then reorganized the remediation checklist according to this logic. Secrets scanning was added to pre-commit hooks while mandatory CI scanning was retained as a separate safeguard; generic IAM roles were broken down into least-privilege permissions tailored to specific services; the “warn” setting in Trivy’s access controls was changed to “fail” for the relevant high-risk findings; and Lacework deployment was brought forward by two quarters. In this illustrative follow-up, the team reviews its attack-path inventory six months later and finds substantially fewer unresolved high-risk paths. The intended lesson is not that accountability guarantees a particular percentage reduction, but that assigning ownership to individual control gaps makes remediation measurable and easier to track.

At Meridian Freight, the changes within Priya’s team seem far more subdued: the checklist has been pinned to the team wiki’s homepage, EPSS and KEV have been integrated into the alert pipeline, and the number of Semgrep custom rules has grown from one to over forty—half of which were drafted by AI and refined by humans. The daily alert volume on the on-call dashboard has stabilized at a level that a single on‑call engineer can handle effectively. There have been no dramatic incidents, nor any high‑level accolades—and among all the possible states of a security team’s operations, those in the “subdued” category carry particular weight, as anyone in the field knows well.

This setup isn’t as expensive as you might think, nor does it have to be implemented all at once. A practical starting point is to take stock of one key question: from the code layer to the runtime, does each layer currently have a “judge,” and who is that judge? This assessment typically takes only about ten minutes. The resulting procurement and remediation lists will align far more closely with your current situation than any industry report could. Tools become obsolete, vendors undergo mergers and acquisitions, and scoring frameworks change names. What truly endures at the levels of cloud security and supply-chain security is sensitivity to the “seams”: attackers never target the tools themselves; they exploit the vulnerabilities in the seams. By assigning a clear point of accountability to every single seam—whether it’s an individual, a rule, or a human‑validated model—the entire system becomes robust and sustainable.

References

CISA, continuously maintained Known Exploited Vulnerabilities (KEV) Catalog
https://www.cisa.gov/known-exploited-vulnerabilities-catalog
FIRST, continuously maintained Exploit Prediction Scoring System (EPSS)
https://www.first.org/epss/
OWASP Foundation, continuously maintained OWASP Dependency-Track
https://owasp.org/projects/dependency-track
SLSA, continuously maintained Provenance
https://slsa.dev/spec/v1.2/provenance

Menu