How DevSecOps verifies compliance with security standards — not finding new vulnerabilities, but verifying that established security controls are still in place and functioning.
Vulnerability scanning finds NEW problems. Compliance verification checks that EXISTING controls are still working. Authentication still enforced? Secrets still managed? Dependencies still pinned? Controls that were implemented don't erode silently.
| Control | How to Verify | Where |
|---|---|---|
| JWT tokens used (not session cookies) | Check auth middleware | fleet/infra/ auth code |
| Token expiry configured | Check config | .env, fleet.yaml |
| Refresh token rotation | Check auth flow | auth daemon |
| API endpoints require auth | Check middleware attachment | all route files |
| No hardcoded credentials | Scan for patterns | all source files |
| Control | How to Verify | Where |
|---|---|---|
| Request size limits | Check middleware/config | API entry points |
| Content-type validation | Check request handling | API handlers |
| SQL/command injection prevention | Check query construction | database queries, subprocess calls |
| Path traversal prevention | Check file operations | any file read/write |
| Control | How to Verify | Where |
|---|---|---|
| .env gitignored | Check .gitignore | .gitignore |
| No secrets in code | Secret scan | all source files |
| API keys from env vars | Check config loading | config_loader.py |
| Secrets not logged | Check log statements | all logger.* calls |
| Example files have placeholders | Check .env.example | .env.example, *.example |
| Control | How to Verify | Where |
|---|---|---|
| Python deps pinned | Check requirements.txt | requirements.txt, pyproject.toml |
| GitHub Actions SHA-pinned | Check workflow files | .github/workflows/*.yml |
| Docker base images pinned | Check Dockerfiles | Dockerfile, docker-compose |
| No known critical CVEs | Run pip audit | dependencies |
| Control | How to Verify | Where |
|---|---|---|
| MC backend not exposed externally | Check port bindings | docker-compose.yaml |
| IRC not accessible externally | Check miniircd config | scripts/setup-irc.sh |
| Gateway auth enabled | Check gateway config | gateway config |
| File permissions appropriate | Check sensitive files | .env, keys, certs |
Your sub-agents handle the mechanical scanning:
Agent: secret-detector — scan for exposed credentials
Agent: security-auditor — OWASP-based code audit
Agent: dependency-scanner — CVE database check
For each category above, check: is the control STILL in place?
## Security Compliance Report — {date}
### Authentication: {COMPLIANT / NON-COMPLIANT}
- JWT auth: ✓ enforced
- Token expiry: ✓ configured (1h access, 7d refresh)
- Hardcoded creds: ✓ none found
### Input Validation: {COMPLIANT / NON-COMPLIANT}
- Request limits: ✓ configured
- Injection prevention: ⚠ 1 finding (fleet/infra/db.py:142 — string interpolation)
### Secret Management: {COMPLIANT / NON-COMPLIANT}
- .env gitignored: ✓
- No secrets in code: ✓
- Example files clean: ✓
### Dependencies: {COMPLIANT / NON-COMPLIANT}
- Pinned: ✓
- CVEs: ⚠ 1 medium (requests 2.28.0)
- SHA-pinned actions: ✓
### Infrastructure: {COMPLIANT / NON-COMPLIANT}
- Ports: ✓ internal only
- Auth: ✓ enabled
### Overall: COMPLIANT WITH WARNINGS (2 findings)
fleet_alert(severity="high", category="security") + create fix task[security, compliance] + track in next scanYour compliance verification integrates with:
The compliance verification is the AGGREGATE view — combining findings from all your CRONs into a unified compliance posture.
This is ASSURANCE — verifying that controls already implemented are still functioning. The immune system for security.