Question 1/10
How does your organization ensure software projects, including AI-generated code, are tracked and uniformly tested for security vulnerabilities?
We rely on developers to manually register their own projects for security testing; coverage gaps are common.
We maintain a partial project inventory, but new repositories and AI-generated codebases frequently slip through without testing.
We synchronize with our source code repositories on a scheduled basis, but project onboarding still requires a manual step.
Security testing enrollment is fully automated. Every repository across all source code management platforms is continuously tracked, including AI-generated codebases, with no manual registration required.
How consistently are security policies enforced across all development teams and branches, including pull requests and merge events?
No centrally-enforced security policy exists. Teams self-select their own testing depth.
A security policy exists, but it is applied inconsistently across teams and projects.
We have centralized security policies, but enforcement at the branch and pull request level still requires manual intervention.
Security policy is set centrally and applied automatically and uniformly across every branch, pull request, and merge event. No team decides its own testing level.
How complete is your Software Bill of Materials (SBOM)? Does it cover compiled binaries, open source snippets, and AI models from repositories such as Hugging Face?
We have no formal SBOM process; our component inventory is largely unknown.
We generate SBOMs for major projects but miss compiled binaries, open source snippets, and AI models.
Our SBOM covers most open source dependencies but lacks complete visibility into AI models and compiled binaries.
We generate a complete SBOM across all languages, compiled binaries, AI-generated code, and AI models—eliminating the false negatives that make supply chain attacks possible.
Where does your team source vulnerability intelligence? And how quickly does that data reach you relative to active exploit availability?
We rely primarily on the National Vulnerability Database (NVD) and vendor patch notices, often learning about issues after exploits are already circulating.
We supplement the NVD with some community feeds, but enrichment coverage and timing are inconsistent.
We use enriched feeds with CVSS scores and Known Exploited Vulnerability (KEV) listings, but we lack reachability and real-time exploitability context.
We use a dedicated vulnerability intelligence feed that publishes enriched advisories significantly ahead of NVD, with hourly updates during active zero-day events, temporal scoring, and contextual priority tags—so our teams act before exploits reach the wild.
How does your team prioritize which vulnerabilities to remediate first, especially when exploit timelines are collapsing from weeks to hours?
We work through findings by CVSS severity score or NVD publication order alone.
We factor in severity scores and some KEV data, but exploitability context is limited.
We use CVSS, KEV listings, and reachability analysis, but triage remains a largely manual workflow.
We combine real-time exploitability signals, KEV listings, CVSS scores, and reachability assessments to automatically surface the highest-risk components first. Our triage runs at machine speed, not human speed.
Is Mean Time to Remediate (MTTR) actively measured, reported, and tied to formal SLAs across your AppSec program?
MTTR is not tracked; remediation happens on a best-effort basis with no defined expectations.
We track MTTR informally, but it is not tied to SLAs or included in leadership reporting.
MTTR is measured and reported to security leadership, but remediation SLAs are inconsistently enforced across teams.
MTTR is a board-level risk metric with formally enforced SLAs. Automated remediation workflows continuously compress MTTR by eliminating the manual triage-to-ticket loop.
To what extent does your organization use AI to automate vulnerability remediation, including generating code fixes, upgrade pull requests, and remediation recommendations?
Remediation is entirely manual—developers receive scan findings and fix on their own schedule.
We have some automation for routine dependency upgrades, but code-level fixes still require direct developer effort.
We use AI-assisted fix suggestions in the developer environment, but automated pull request generation is not yet in place.
We run end-to-end agentic find-prioritize-fix workflows that automatically generate replacement code, upgrade pull requests, and validate that component changes haven’t broken dependent code.
Can your security program detect malicious supply chain activity, such as lookalike packages, compromised committers, and anomalous behavior, before a CVE is published?
No. Our supply chain defense is entirely CVE-reactive. Zero-day supply chain attacks would go undetected.
We monitor community threat feeds, but we have no automated anomaly detection correlated against our own component inventory.
We perform periodic manual reviews for suspicious packages, but continuous behavioral monitoring is not in place.
We use AI to continuously probe our component inventory for lookalike packages, suspicious committer behavior, and anomalous activity, detecting high-risk components before a vulnerability is formally disclosed.
How auditable and compliance-ready is your application security analysis? Can your toolchain produce deterministic, reproducible results that hold up in regulatory reviews?
Our analysis is primarily AI-generated or manual. Results are inconsistent and not suitable for audit or compliance review.
We have some deterministic scanning in place, but significant gaps remain for compliance and auditability purposes.
Our static analysis (SAST) and software composition analysis (SCA) produce auditable results, but AI-assisted analysis has not yet been integrated into the compliance workflow.
We run a hybrid architecture—deterministic scanning as the auditable, reproducible foundation, with AI-powered analysis layered on top for deeper insights and automated remediation—delivering compliance-grade results at enterprise scale.
Has your organization begun the transition from script-based DevSecOps to a secure agentic SDLC, where AI continuously orchestrates security testing, triage, remediation, and validation?
Our DevSecOps is script-based and reactive; there is no roadmap toward agentic security workflows.
We are evaluating agentic security tools, but we have no production deployment or defined transition plan.
We have deployed AI-assisted triage and some automated fixes, but end-to-end agentic orchestration is not yet fully operational.
We operate a continuous agentic security layer that orchestrates test-triage-fix-retest cycles automatically, with human sign-off as the only manual checkpoint.