DAST & Penetration Testing Policy
Document control
| Field | Value |
|---|---|
| Owner | Ron Benisty — CTO & CSO (ron.b@iontwrks.com) |
| Status | Approved |
| Version | 1.0 |
| Classification | Confidential |
| Approved by | Ron Benisty — CTO & CSO |
| Approval date | 2026-05-26 (Tuesday) |
| Last reviewed | 2026-05-26 |
| Review cycle | Annual — next review due May 2027 |
| Parent policy | Secure SDLC (SSDLC) |
Satisfies ISO/IEC 27001:2022 A.8.29 (security testing in development & acceptance) and NIST SSDF PW.8 (test executable code to identify vulnerabilities). Closes Gap 7 of the SSDLC gap analysis.
1. Purpose
Two complementary security-testing disciplines, owned by one policy:
- DAST (Dynamic Application Security Testing) — automated scanning of the deployed application from the outside, runs continuously. Catches the breadth of known vulnerability patterns.
- Penetration testing — human-driven adversarial testing by a qualified third party, runs periodically. Catches the depth of business-logic flaws and chained attacks that no scanner can reach.
SAST + SCA (in the Release Gate Criteria) finds known patterns in the source. DAST + pen-testing covers the runtime side: what the deployed application actually exposes.
2. Scope
| Discipline | Scope |
|---|---|
| DAST — automated | Every deployed nonprod build (admin portal, customer portal, public REST API, internal GraphQL API) |
| Pen-testing — periodic | The full platform at the annual cadence; targeted retests of specific areas on major releases |
3. DAST — automated dynamic scanning
3.1 Tool stack (locked)
| Tool | Mode | Cadence | Runtime |
|---|---|---|---|
| OWASP ZAP | Baseline (passive) | Every PR after nonprod deploy | ~5 min |
| OWASP ZAP | Full (active) | Nightly at 02:00 UTC against the latest nonprod build | ~60 min |
| Nuclei | Templated CVE / vuln scan | Weekly Saturday at 04:00 UTC against nonprod | ~30 min |
All three run as GitHub Actions; results post to GitHub Issues with the source label set.
3.2 Environment
DAST runs only against nonprod. The Cloudflare WAF + ALB security group + AWS IP allowlist on the nonprod account specifically allow the GitHub Actions runner range. Per the Audit Testing Scope Policy §4, active scanning against production is forbidden without a separately approved engagement.
3.3 Configuration discipline
- ZAP context + Nuclei templates stored at
security/dast/in the repo, versioned with the codebase. - Baseline scan: passive only — observes traffic, won't generate active payloads that could break the app.
- Full scan: active — runs against a fresh nonprod deploy with seeded synthetic test data (no real customer data; per Test Data Protection).
- Authentication: ZAP uses a dedicated DAST-only WorkOS user account with limited scope (one synthetic tenant). Never uses real customer credentials.
- Out-of-scope for active scan: email-triggering endpoints (SES routing disabled for the DAST account), webhook calls to real third-party systems, file uploads above test thresholds. Configured in the ZAP context file.
3.4 Finding integration
Every DAST finding becomes a GitHub Issue with labels: vuln, source:zap or source:nuclei, severity:<tier>. Findings flow through the standard Vulnerability Management process:
- CVSS v3.1 scoring applied at triage.
- SLAs: Critical ≤ 7 d · High ≤ 30 d · Medium ≤ 90 d · Low ≤ 120 d.
- Exception process with CTO & CSO approval and compensating-control requirement applies identically.
- Recurring class (third occurrence in 12 months) triggers a Root-Cause Analysis.
3.5 False-positive management
ZAP and Nuclei both produce false positives. The standard approach:
- Tool-level suppressions live in
security/dast/zap-ignore.ymlandsecurity/dast/nuclei-ignore.yml. - Each suppression requires: rule ID, reason, linked GitHub Issue, expiration date.
- Suppressions enter the repo via CODEOWNER-approved PR.
- Active suppressions are reviewed monthly as part of the Vulnerability Management monthly review. Expired suppressions are deleted; if the rule is still false-positive the suppression is re-justified with a new expiration.
4. Penetration testing — third-party human testing
4.1 Cadence
- Annual full pen-test — every February, aligned with the SSDLC annual review and the annual Risk Assessment cycle.
- Targeted retest within 30 days of any major release that touches:
- Authentication or session management (Authentication)
- Tenant-isolation code or pattern (Multi-Tenancy)
- Cryptography primitives (Cryptography Standard)
- A new external interface (new public API, new sub-processor integration, new portal section)
4.2 Vendor selection criteria
The specific pen-test vendor is selected via a procurement process and named in a separate contract (not in this policy). Any selected vendor must meet all of the following baseline criteria, documented and verified at the time of selection:
| Criterion | Requirement |
|---|---|
| Credentials | Analysts on the engagement hold CREST, OSCP, OSCE, or equivalent certifications |
| Track record | Documented prior engagements with multi-tenant B2B SaaS, ideally compliance / security products |
| Methodology | Documented alignment with OWASP WSTG (Web Security Testing Guide) and/or NIST SP 800-115 |
| Data residency | If the engagement involves any production-shape data, vendor must support EU residency (Israel-EU adequacy) or Israeli residency for Nimbus-aligned scenarios |
| Insurance | Professional indemnity + cyber-incident coverage at the levels stipulated in S.E.T's own contractual minima |
| Confidentiality | NDA signed before any scope documents are shared; final report delivered via secure channel only (encrypted email / secure portal) |
| Vendor rotation | The same vendor may be retained for up to 3 consecutive years; rotation mandatory afterward to bring fresh perspective |
Owner: CTO & CSO. Vendor selection records (RFP if applicable, contract, scope statement, signed-off criteria checklist) are retained per the Evidence Collection & Retention Policy.
4.3 Scope
Annual full pen-test — in-scope
- External attack surface: both portals (admin + customer), the public REST API, all exposed webhooks.
- Authenticated application testing: credentialed access to both admin and customer portals; tester acts as both an MSSP admin and an MSSP's end client.
- Tenant-isolation testing: explicit attempts to cross-tenant boundaries from legitimately-authenticated sessions (this is the most important class for our product).
- Authentication & session management: token reuse, replay, fixation, privilege escalation, JWT manipulation.
- API security: authorization checks per endpoint, rate limiting, mass assignment, BOLA / IDOR, GraphQL-specific (query depth/complexity bypass, introspection-disabled checks).
Annual full pen-test — out-of-scope
- Sub-processor systems we don't operate (WorkOS, AWS, Cloudflare, Logz.io, GitHub) — their pen-test programs are evidenced by their SOC 2 reports.
- Social engineering of S.E.T employees — separate concern, not application security.
- Physical security — not applicable; S.E.T runs entirely on cloud.
- Denial-of-service attacks — could disrupt nonprod and yield no useful finding (Cloudflare absorbs DDoS upstream anyway).
- Production environment — without specific written approval per Audit Testing Scope §4.
Targeted retest scope
Limited to the area covered by the major release. Specified in a short Statement of Work per retest.
4.4 Engagement process
| # | Step | Owner | Output / artifact |
|---|---|---|---|
| 1 | Scope agreement signed | CTO & CSO + vendor | Signed Statement of Work, retained as evidence |
| 2 | Test environment provisioned | S.E.T team | Dedicated nonprod tenant + synthetic test data + vendor credentials |
| 3 | Kickoff call | CTO & CSO + vendor lead | Kickoff notes; emergency-abort contact established |
| 4 | Active testing | Vendor | Daily progress; Sev 1 findings escalated immediately to the Incident Response Plan |
| 5 | Draft report | Vendor | Draft delivered via secure channel to CTO & CSO |
| 6 | Walkthrough + remediation planning | CTO & CSO + vendor | Final report; remediation plan with SLAs per Vulnerability Management |
| 7 | Remediation | S.E.T team | PRs against each finding; same SLA tiers as DAST findings |
| 8 | Verification retest | Vendor (or in-house against the same scope where contracted) | Retest report |
| 9 | Engagement record archived | CTO & CSO | All artifacts filed in the Evidence Register |
4.5 Finding integration
Every pen-test finding becomes a GitHub Issue with labels: vuln, source:pentest, severity:<tier>. Flow through Vulnerability Management:
- Vendor's severity rating reviewed by CTO & CSO; CVSS v3.1 score finalized at triage; disagreements with the vendor's rating documented on the issue.
- SLAs apply: Critical ≤ 7 d · High ≤ 30 d · Medium ≤ 90 d · Low ≤ 120 d, counted from triage-with-S.E.T-team.
- Verification: same retest by the vendor (or in-house if the engagement does not include retest).
5. Coordination with Audit Testing Scope
This policy operates within the rules of the Audit Testing Scope Policy:
- DAST against prod is forbidden — DAST runs against nonprod only.
- Pen-test scope agreement must be signed ≥ 5 business days before testing begins.
- Blackout windows: no pen-testing during an active production incident, during planned major deploys, or during the customer's contractual notice period for testing.
- Emergency abort: CTO & CSO may suspend any active testing at any time with immediate written notice to the vendor.
6. Evidence + retention
| Artifact | Retention |
|---|---|
| Annual pen-test report + remediation evidence | ≥ 24 months |
| Targeted retest reports | ≥ 24 months |
| DAST scan results (per run) | ≥ 12 months in GitHub Actions artifacts |
| DAST findings (as GitHub Issues) | Per Vulnerability Management retention |
| Vendor contracts + Statements of Work | Lifetime of vendor relationship + 24 months thereafter |
| Vendor selection records (criteria checklist, RFP, decision rationale) | ≥ 24 months |
| DAST suppressions | Lifetime of suppression + 12 months |
All per the Evidence Collection & Retention Policy.
7. Document change history
| Version | Date | Author | Description of change | Approved by |
|---|---|---|---|---|
| 1.0 | 2026-05-26 | Ron Benisty (CTO & CSO) | Initial version — DAST stack locked (OWASP ZAP baseline per PR + ZAP full nightly + Nuclei weekly, nonprod-only, findings into Vulnerability Management). Pen-testing cadence locked (annual full + targeted retests on major releases). Vendor criteria locked; specific vendor selection deferred to procurement contract. | Ron Benisty (CTO & CSO) |