Security Testing Policy
Security Testing Policy
Organization: {{ORG_NAME}} Policy Number: POL-SEC-TEST-{{NUMBER}} Version: {{VERSION}} Date: {{DATE}} Author: {{AUTHOR}} Status: Draft | In Review | Approved Reviewers: {{REVIEWERS}} Next Review: {{REVIEW_DATE}} Classification: Confidential
Document History
| Version | Date | Author | Changes |
|---|---|---|---|
| 0.1 | {{DATE}} | {{AUTHOR}} | Initial draft |
1. Purpose & Scope
Purpose: This policy defines the security testing methodology, tools, frequency, and remediation requirements for all systems operated by {{ORG_NAME}}. Security testing is mandatory and non-negotiable — no system goes to production without completing applicable security tests.
Scope:
- All production applications and APIs
- All infrastructure (cloud, on-premises, containers)
- All internal tools with access to production data
- All CI/CD pipelines and build systems
- All third-party integrations where {{ORG_NAME}} controls the integration code
Policy Owner: {{CISO_NAME}} ({{CISO_EMAIL}}) Operational Owner: Security team
2. Security Testing Methodology
Approach: Shift-left security — testing integrated throughout development, not bolted on at the end.
Testing layers:
Development Phase
├── SAST — Static code analysis (every commit)
├── SCA — Dependency vulnerability scan (every commit)
└── IaC Security Scan — Infrastructure-as-code review (every commit)
Build / CI Phase
├── SAST — Full codebase scan (every PR)
├── SCA — License + vulnerability check (every PR)
├── Container scanning — Image vulnerability analysis (every build)
└── Secret scanning — Detect leaked credentials (every commit)
Deployment Phase
├── DAST — Dynamic scan against staging (every deployment)
└── API security scan — Endpoint fuzzing (every deployment)
Operational Phase
├── IAST — Runtime analysis in staging (continuous)
├── Vulnerability assessment — External attack surface (quarterly)
├── Penetration test — Manual expert testing (annual)
└── Red team exercise (annual for critical systems)
3. Testing Types, Tools & Schedule
3.1 SAST — Static Application Security Testing
Purpose: Detect security vulnerabilities in source code at development time.
| Property | Value |
|---|---|
| Tool(s) | {{SAST_TOOL}} (e.g., Semgrep, SonarQube, CodeQL, Snyk Code) |
| Frequency | Every commit (incremental) + every PR (full scan) |
| Languages covered | {{LANGUAGE_LIST}} |
| Integration | Git pre-commit hook (incremental) + CI pipeline (full) |
| Blocking | YES — PR cannot merge if Critical or High findings unresolved |
| Results location | {{DASHBOARD_URL}} |
SAST rules in scope:
- OWASP Top 10
- SQL injection, command injection, LDAP injection
- XSS (reflected, stored, DOM-based)
- Path traversal / local file inclusion
- Insecure deserialization
- Hardcoded credentials / secrets
- Insecure cryptography usage
- Authentication and session management flaws
- Insecure direct object references
Configuration:
# .sast-config.yml
severity_threshold: medium # Block on medium and above
exclude_paths:
- "**/__tests__/**"
- "**/node_modules/**"
- "**/*.test.ts"
custom_rules:
- {{CUSTOM_RULE_FILE}}
False positive handling: Developers may suppress findings with an inline comment — requires reviewer approval and explanation. All suppressions are audited quarterly.
3.2 DAST — Dynamic Application Security Testing
Purpose: Detect runtime vulnerabilities by sending attack traffic to a running instance.
| Property | Value |
|---|---|
| Tool(s) | {{DAST_TOOL}} (e.g., OWASP ZAP, Burp Suite Enterprise, Nuclei) |
| Frequency | Every deployment to staging + weekly full scan of staging |
| Target | https://staging.{{DOMAIN}} — NEVER production without explicit approval |
| Integration | Post-deployment CI step |
| Blocking | YES — deployment halted if Critical finding discovered |
| Results location | {{DASHBOARD_URL}} |
DAST scan scope:
- All API endpoints (authenticated + unauthenticated)
- Authentication flows (login, registration, password reset)
- File upload endpoints
- Search and filter parameters
- Error handling (stack trace disclosure)
- Security headers presence and correctness
- SSL/TLS configuration
DAST authentication setup:
# dast-auth.yml
loginUrl: https://staging.{{DOMAIN}}/auth/login
loginRequestData:
email: "{{DAST_TEST_USER_EMAIL}}"
password: "{{DAST_TEST_USER_PASSWORD}}"
indicateSuccessPattern: "access_token"
scanAsAuthenticatedUser: true
Production DAST: Requires written approval from CISO + Engineering Lead. Scoped to non-destructive read-only tests only. Scheduled during off-peak hours.
3.3 SCA — Software Composition Analysis
Purpose: Identify known vulnerabilities (CVEs) in open source dependencies. Verify license compliance.
| Property | Value |
|---|---|
| Tool(s) | Snyk / Dependabot / OWASP Dependency-Check |
| Frequency | Every commit (Dependabot) + weekly full scan |
| Blocking | YES — PR cannot merge with Critical CVE (unresolved) |
| License check | YES — copyleft licenses (GPL, AGPL) require legal review |
| Results location | {{DASHBOARD_URL}} |
Dependency update policy:
- Security patches: Merge within SLA (see §4)
- Minor updates: Merge within 14 days
- Major updates: Planned migration within 90 days
Approved license list: MIT, Apache 2.0, BSD (2-clause, 3-clause), ISC, MPL 2.0
Requires legal review: GPL, LGPL, AGPL, EUPL, CDDL
3.4 IAST — Interactive Application Security Testing
Purpose: Runtime security analysis during integration/acceptance testing. Combines benefits of SAST and DAST.
| Property | Value |
|---|---|
| Tool(s) | {{IAST_TOOL}} (e.g., Contrast Security, Seeker, HCL AppScan) |
| Environment | Staging only — never production |
| Frequency | Continuous during staging test suite execution |
| Integration | Test runner + agent sidecar |
| Blocking | Findings reviewed within 48h — blocks next release if Critical |
3.5 Container / Infrastructure Scanning
| Property | Value |
|---|---|
| Tool(s) | Trivy / Grype / AWS Inspector |
| Scope | All container images + Kubernetes manifests + Terraform/CDK code |
| Frequency | Every image build + daily registry scan |
| Blocking | YES — Critical CVEs in base image block deployment |
| IaC scanning | Checkov / tfsec — every PR |
Container hardening requirements:
- Non-root user in Dockerfile
- Read-only root filesystem where possible
- No secrets in image layers
- Base image: distroless or minimal (Alpine)
- No unnecessary packages
3.6 Penetration Testing
Purpose: Expert manual security assessment simulating a real attacker.
| Property | Value |
|---|---|
| Frequency | Annual minimum; after major architectural changes |
| Scope | Full application + API + infrastructure + social engineering (optional) |
| Provider | {{PENTEST_FIRM}} — retainer: {{RETAINER_STATUS}} |
| Methodology | OWASP Testing Guide v4.2 + PTES |
| Rules of engagement | Written agreement required before each engagement |
| Output | Full findings report + executive summary + remediation guidance |
| Blocking | Critical findings: system taken offline until remediated |
Penetration test scope template:
In-scope:
- Production URLs: https://{{DOMAIN}}, https://api.{{DOMAIN}}
- Authentication flows (login, registration, MFA, SSO)
- All authenticated API endpoints
- File upload functionality
- Administrative functions
- Cloud infrastructure (read-only reconnaissance)
Out-of-scope:
- Denial of service attacks
- Social engineering of staff without prior approval
- Physical penetration testing (unless separately scoped)
- Third-party services (AWS infrastructure itself, Stripe, etc.)
- Automated scanning beyond initial reconnaissance (provider uses their own tools)
Rules of engagement:
- Testing window: {{START_DATE}} to {{END_DATE}}
- Notify before testing: {{CONTACT}} via {{METHOD}}
- Halt on critical finding: Immediately notify {{SECURITY_CONTACT}}
3.7 Red Team Exercises
Purpose: Adversarial simulation to test detection and response capabilities, not just prevention.
| Property | Value |
|---|---|
| Frequency | Annual for critical systems |
| Scope | Full kill-chain simulation (initial access → lateral movement → exfiltration) |
| Provider | {{RED_TEAM_FIRM}} |
| Blue team awareness | Only executive sponsor knows — security team is unaware (true test) |
| Output | Red team report + purple team exercise (joint analysis) |
4. Vulnerability Classification & Remediation SLAs
4.1 Severity Classification (CVSS v3.1)
| Severity | CVSS Score | Definition | Example |
|---|---|---|---|
| Critical | 9.0 – 10.0 | Remote code execution, full auth bypass, mass data exfiltration without auth | Log4Shell (CVSS 10.0) |
| High | 7.0 – 8.9 | Privilege escalation, auth bypass (authenticated), significant data exposure | SQLi with auth |
| Medium | 4.0 – 6.9 | Limited data exposure, CSRF, stored XSS, insecure config | Reflected XSS |
| Low | 0.1 – 3.9 | Minor information disclosure, theoretical risk | Version disclosure |
| Informational | N/A | Best practice recommendation, no direct exploitability | Weak password policy |
4.2 Remediation SLAs
| Severity | SLA | Action on Breach of SLA |
|---|---|---|
| Critical | Immediate containment in 4h; full remediation in 24 hours | Emergency escalation — CISO + CEO. System taken offline if risk cannot be mitigated. |
| High | 7 calendar days | Escalate to CISO. Engineering manager must approve extension request. |
| Medium | 30 calendar days | Engineering lead tracks. Exception requires security team sign-off. |
| Low | 90 calendar days | Tracked in backlog. Reviewed in quarterly security review. |
| Informational | Next sprint (best effort) | Tracked but not SLA-bound. |
SLA tracking: All findings in {{ISSUE_TRACKER}} with label security-finding + severity label.
Exception process: Written request to Security Lead → CISO approval → compensating control required → max extension = 1× original SLA.
5. Security Code Review Checklist
Every PR touching authentication, authorization, payment, PII, or cryptography requires a security review:
Authentication & Authorization:
- No hardcoded credentials or secrets
- Password hashing uses Argon2id or bcrypt (cost ≥ 12)
- JWT validation: signature, expiry, issuer, audience
- Authorization checked on EVERY protected endpoint (not just at route level)
- No
isAdminflag from user-supplied input - Session tokens invalidated on logout
Input Validation:
- All user inputs validated (type, length, format, allowed values)
- Parameterized queries for all database operations (no string concatenation)
- File uploads: type validated by magic bytes, filename sanitized, stored outside webroot
- No eval(), exec(), or shell command interpolation with user input
- HTML output properly escaped (no innerHTML with user data)
Cryptography:
- No MD5, SHA-1, DES, RC4
- Random values generated with CSPRNG
- IVs/nonces are random and never reused
- Private keys not in source code or logs
Error Handling:
- No stack traces or internal details in API error responses
- Errors logged internally but not exposed externally
- No user enumeration (same response for "user not found" and "wrong password")
Data Handling:
- PII not logged in plaintext
- Sensitive data not in query parameters (use POST body)
- No unnecessary data retention (data minimization)
- Proper data deletion/anonymization on account close
Dependencies:
- New dependency reviewed for known CVEs before adding
- No end-of-life dependencies introduced
- License compatible with project license
6. Bug Bounty Program
Status: {{ACTIVE / PLANNED / NOT_APPLICABLE}}
Platform: {{HACKERONE / BUGCROWD / INTIGRITI}} Scope: {{IN_SCOPE_URLS}} Out of scope: {{OUT_OF_SCOPE}}
Reward structure:
| Severity | Reward Range |
|---|---|
| Critical | {{AMOUNT}} |
| High | {{AMOUNT}} |
| Medium | {{AMOUNT}} |
| Low | No reward (acknowledgment only) |
Response SLAs (to researcher):
- Acknowledgment: 1 business day
- Triage/validation: 5 business days
- Remediation update: Per §4.2 SLAs
- Reward payment: Within 14 days of fix deployment
Safe harbor: Researchers acting in good faith following disclosure policy are protected from legal action.
7. Security Testing in CI/CD Pipeline
flowchart LR
COMMIT[Developer\nCommit] -->|Pre-commit hook| SAST_INC[SAST\nIncremental]
SAST_INC -->|Pass| PUSH[Git Push]
PUSH --> PR[Pull Request]
PR --> SAST_FULL[SAST\nFull Scan]
PR --> SCA[SCA\nDependency]
PR --> SECRET[Secret\nScanning]
PR --> IAC[IaC\nSecurity Scan]
SAST_FULL & SCA & SECRET & IAC -->|All pass| BUILD[Build\nContainer]
BUILD --> CONTAINER_SCAN[Container\nScan]
CONTAINER_SCAN -->|Pass| STAGING[Deploy to\nStaging]
STAGING --> DAST[DAST\nScan]
STAGING --> IAST[IAST\nRuntime]
DAST & IAST -->|Pass| GATE{Security\nGate}
GATE -->|Pass| PROD[Deploy to\nProduction]
GATE -->|Fail| BLOCK[Block Deploy\nAlert Security]
Pipeline security gate criteria:
| Gate | Tool | Blocking Criteria |
|---|---|---|
| Pre-commit | SAST (incremental) | Critical findings in changed files |
| PR gate 1 | SAST (full) | Any Critical or High (unresolved) |
| PR gate 2 | SCA | Critical CVE in dependencies |
| PR gate 3 | Secret scan | Any detected secret |
| PR gate 4 | IaC scan | Critical misconfiguration |
| Post-build | Container scan | Critical CVE in base image or packages |
| Post-staging | DAST | Critical or High dynamic finding |
8. Reporting Format
8.1 Individual Finding Report
Finding ID: VULN-{{YEAR}}-{{SEQUENCE}}
Title: {{SHORT_DESCRIPTION}}
Severity: Critical / High / Medium / Low
CVSS Score: {{SCORE}} (v3.1)
CVSS Vector: {{VECTOR_STRING}}
Description:
{{DETAILED_DESCRIPTION_OF_VULNERABILITY}}
Affected Systems:
- {{SYSTEM_1}}: {{URL_OR_CODE_LOCATION}}
- {{SYSTEM_2}}: {{URL_OR_CODE_LOCATION}}
Proof of Concept:
{{STEPS_TO_REPRODUCE}}
{{SCREENSHOTS_OR_CURL_COMMANDS}}
Impact:
{{WHAT_AN_ATTACKER_CAN_DO_IF_EXPLOITED}}
Remediation:
{{SPECIFIC_REMEDIATION_STEPS}}
References:
- CWE-{{N}}: {{CWE_DESCRIPTION}}
- OWASP: {{OWASP_CATEGORY}}
- CVE-{{N}} (if applicable)
Owner: {{ASSIGNED_ENGINEER}}
SLA: {{DUE_DATE}}
Status: Open / In Progress / Resolved / Accepted Risk
8.2 Security Testing Summary Report
Produced after each: Penetration test, quarterly DAST, quarterly vulnerability assessment.
Report period: {{START_DATE}} to {{END_DATE}}
Report type: Penetration Test / DAST / Vulnerability Assessment
Conducted by: {{INTERNAL / EXTERNAL_FIRM}}
EXECUTIVE SUMMARY
Total findings: Critical: {{N}} | High: {{N}} | Medium: {{N}} | Low: {{N}}
Findings resolved within SLA: {{N}}/{{TOTAL}} ({{PERCENT}}%)
Risk trend vs previous period: Improving / Stable / Worsening
TOP FINDINGS BY SEVERITY
[Table of Critical and High findings]
REMEDIATION STATUS
[Table of all findings with status and owner]
RECOMMENDATIONS
1. {{STRATEGIC_RECOMMENDATION_1}}
2. {{STRATEGIC_RECOMMENDATION_2}}
9. Metrics & KPIs
| Metric | Target | Reporting Frequency |
|---|---|---|
| Critical findings resolved within SLA | 100% | Monthly |
| High findings resolved within SLA | ≥ 95% | Monthly |
| Mean time to detect (MTTD) | < {{N}} days | Quarterly |
| Mean time to remediate (MTTR) — Critical | < 24 hours | Monthly |
| MTTR — High | < 7 days | Monthly |
| SAST false positive rate | < {{PERCENT}}% | Quarterly |
| % of deployments with passing security gate | 100% | Monthly |
| Open High+ findings (backlog) | < {{N}} | Monthly |
| Penetration test — critical findings closed | 100% within 30 days | Per test |
Security metrics dashboard: {{DASHBOARD_URL}} Quarterly security report: Published to {{RECIPIENTS}} on {{SCHEDULE}}
Approval
| Role | Name | Date | Signature |
|---|---|---|---|
| Author | |||
| CISO | |||
| Engineering Lead | |||
| CTO | |||
| Management |