Methodology & Rollout
Deploying a security tool without organizational change creates friction. We provide the frameworks to embed DevSecOps into your engineering culture smoothly, turning developers into security champions.
Standard Enterprise Rollout Playbook
The two-week pilot comes first; this playbook covers what happens after you decide to roll out across the organisation.
1. Discover
Deploy in monitor-only mode. Integrate with source control and CI/CD without blocking builds. Establish baseline metrics for vulnerability introduction rates and developer workflows.
2. Embed
Roll out IDE plugins to early adopters and security champions. Configure organization-specific policies (e.g., custom secret patterns, internal framework rules) in the policy engine.
3. Measure
Activate soft-blocking in CI/CD. Vulnerabilities generate alerts and pull request comments but can be overridden by developers with justification. Analyze false positive rates.
4. Scale
Enforce hard blocking for critical findings. Findings are exported automatically to Jira or DefectDojo. Close the loop with continuous DevSecOps training.
Security Champions Program
We help you build a Security Champions program: identify developers to advocate for security within their teams, define responsibilities and measurable outcomes, and target training where it is needed most. This is a methodology, not a live gamification feature. Gamified developer training, organisation-wide statistics, and reporting tools are planned for H1 2027.
- Program MethodologyDefine champion responsibilities, review cadence, and team-level outcomes before adding gamification.
- Vulnerability Escape RateEscape rate (%) = 100 × unique findings first detected by a production scan after deployment ÷ all unique findings first detected in the same calendar month. “Production” means the deployed environment identified in the agreed assessment scope. Reopened findings retain their original first-detected date and are not counted twice.
- In-Context TrainingUse reviewed findings in team-led training to explain why a pattern is dangerous and how to avoid it. This program practice does not imply automated training delivery.
Built-in MLSecOps
AI.CleanCode inventories the AI assets in your codebase and applies dedicated MLSecOps checks:
- Inventories models, datasets, vector stores, and agent configurations
- Produces a CycloneDX 1.5 ML-BOM of AI system components
- Checks model licenses for restrictive terms
- Flags insecure AI-specific patterns in data pipelines and agent tooling
Core DevSecOps Metrics
Use these metrics to evaluate the program with your existing review and reporting processes; they do not imply a currently available organisation-wide dashboard.
Report by calendar month in the agreed reporting timezone and assessment scope. Show sample counts alongside results; report N/A for an empty sample or a zero denominator, not zero performance.
MTTR = median elapsed time from the first scan reporting a finding to the first subsequent successful scan covering the same code and check where it no longer appears, grouped by severity and resolution calendar month. Open findings are reported separately; a skipped check or suppressed finding is not a resolution.
Share of pull requests where AI-assisted changes were reviewed by AI.CleanCode before merge.
Exception request rate (%) = 100 × unique findings blocked during the calendar month with an exception requested in that month ÷ all unique findings blocked during that month. Count each finding once, regardless of repeated requests or approval status.