Plan: Penetration Testing & Vulnerability Management
On this page
Status
| Step | Description | Status |
|---|---|---|
1 |
Plan file and nav entry |
Done (2026-03-21) — MR !49 |
2 |
Vulnerability disclosure policy (SECURITY.md) |
Done (2026-03-21) — MR !49 |
3 |
Remediation SLA documentation |
Done (2026-03-21) — MR !49 |
4 |
DAST integration (OWASP ZAP in CI) |
Done (2026-03-21) — MR !49 |
5 |
Penetration test process documentation |
Done (2026-03-21) — MR !49 |
6 |
Vulnerability tracking integration |
Done (2026-03-21) — MR !49 |
7 |
Documentation, commit, push, MR |
Done (2026-03-21) — MR !49 |
Issues: TBD
Branch: feature/pentest-vuln-management
Context
CRAIG has strong static security scanning in CI (SAST via semgrep, secret detection, dependency scanning, container scanning). However, there is no dynamic application security testing (DAST), no vulnerability disclosure policy, no documented pentest process, and no remediation SLAs.
This is primarily a documentation and process plan with one code deliverable (DAST integration).
What Exists Today
-
CI Security Scanning:
.gitlab-ci.ymlincludes 4 GitLab security templates:-
SAST (semgrep)
-
Secret Detection
-
Dependency Scanning (gemnasium)
-
Container Scanning (per-service matrix job)
-
-
Code Quality: Zero
unsafeblocks, all SQL parameterized, PKCE OAuth, CAPTCHA + rate limiting -
NIST Controls:
nist_controlstable with implementation status tracking -
Biennial Security Reviews:
security_reviewstable with scheduled/completed workflow
Scope
In scope:
-
SECURITY.md— vulnerability disclosure policy at repository root -
Remediation SLA documentation (time-to-patch by severity)
-
DAST job in CI using OWASP ZAP against devstack
-
Penetration test process documentation (how to commission, scope, frequency)
-
Integration of vulnerability findings with existing
nist_controlstracking
Out of scope:
-
Conducting an actual penetration test (operational activity)
-
Web Application Firewall (WAF) configuration (infrastructure)
-
Bug bounty program (organizational decision)
Design
Step 2: SECURITY.md
File: SECURITY.md (repository root)
Standard vulnerability disclosure policy:
# Security Policy
## Supported Versions
| Version | Supported |
|---------|-----------|
| 0.1.x | Yes |
## Reporting a Vulnerability
If you discover a security vulnerability in CRAIG, please report it
responsibly:
1. **Do NOT open a public issue.**
2. Email: security@gadhs.example.gov (or use GitLab confidential issues)
3. Include: description, reproduction steps, impact assessment
4. We will acknowledge within 48 hours and provide an initial assessment
within 5 business days.
## Remediation SLAs
| Severity | Time to Patch | Time to Deploy |
|----------|--------------|----------------|
| Critical | 24 hours | 48 hours |
| High | 7 days | 14 days |
| Medium | 30 days | 60 days |
| Low | 90 days | Next release |
## Security Scanning
CRAIG runs automated security scanning on every commit:
- SAST (semgrep) — static analysis
- Secret Detection — credential leak prevention
- Dependency Scanning — known CVE detection
- Container Scanning — image vulnerability assessment
- DAST (OWASP ZAP) — dynamic application testing (main branch)
Step 3: Remediation SLA Documentation
File: docs/modules/ROOT/pages/security-operations.adoc — new page
Documents:
-
Severity classification criteria (CVSS-based)
-
Remediation timelines per severity
-
Escalation procedures
-
Security update release process
-
Notification requirements (who to inform for each severity)
Step 4: DAST Integration
File: .gitlab-ci.yml — add DAST job
dast:
stage: check
image: ghcr.io/zaproxy/zaproxy:stable
services:
- name: docker:27-dind
alias: docker
variables:
DOCKER_HOST: tcp://docker:2376
DOCKER_TLS_CERTDIR: "/certs"
before_script:
- docker compose up -d --wait
script:
- zap-baseline.py -t http://craig-web:8080 -r zap-report.html -J zap-report.json
artifacts:
paths:
- zap-report.html
- zap-report.json
reports:
dast: zap-report.json
rules:
- if: $CI_COMMIT_BRANCH == "main"
allow_failure: true # baseline scan — informational initially
| The exact DAST configuration depends on GitLab runner capabilities. The devstack must be running inside the CI job for ZAP to scan. This may require a DinD (Docker-in-Docker) setup similar to the integration test job. |
Step 5: Penetration Test Process
File: docs/modules/ROOT/pages/security-operations.adoc — add section
Documents:
-
Recommended frequency: annually or after major architectural changes
-
Scope definition template (which services, endpoints, auth flows)
-
Vendor selection criteria
-
Pre-test checklist (snapshot data, notify stakeholders)
-
Post-test report handling (findings → GitLab confidential issues → remediation)
-
Re-test verification process
Step 6: Vulnerability Tracking
Link external vulnerability findings (pentest results, DAST results, dependency scan findings) to the existing nist_controls system:
-
Add
vulnerability_sourcefield to NIST control notes (e.g., "DAST finding: ZAP-10015 — X-Frame-Options not set") -
Create a
vulnerabilitiesview or report that aggregates: CI scan findings + NIST control gaps + pentest findings
This is primarily a documentation/process deliverable, not new API endpoints.
Files Touched
| File | Change |
|---|---|
|
New: vulnerability disclosure policy |
|
New: remediation SLAs, pentest process |
|
Add security-operations page under Operations |
|
Add DAST job (OWASP ZAP baseline scan) |
Verification
-
SECURITY.mdrenders correctly on GitLab -
DAST job runs on main branch without blocking pipeline
-
ZAP report artifact downloadable from CI
-
Security operations page builds in Antora
Documentation Updates
-
docs/modules/ROOT/nav.adoc— add security-operations under Operations -
CHANGELOG.adoc— entry under Unreleased -
docs/modules/ROOT/pages/roadmap.adoc— tick pentest/vuln management item