docs: add external security review engagement scope
This commit is contained in:
@@ -0,0 +1,82 @@
|
||||
# CASAN — External Security Review / Penetration-Test Scope
|
||||
|
||||
This is the procurement and evidence baseline for an **independent** security
|
||||
review before an enterprise pilot. It is not a penetration-test report and must
|
||||
not be used as a claim that CASAN has passed an external assessment.
|
||||
|
||||
## 1. Engagement boundary
|
||||
|
||||
| In scope | Required test focus |
|
||||
|---|---|
|
||||
| Control Panel API, UI, reverse proxy and deployment manifests | authentication boundary, RBAC/SoD, tenant/project isolation, input/output validation, HTTP/TLS configuration |
|
||||
| Harness CLIs and CI workflows | command/path injection, policy bypass, unsafe fallback, artifact/evidence tampering, secret handling and supply-chain controls |
|
||||
| Governed Chat and approval paths | unauthorized tool execution, approval replay/bypass, audit-chain integrity, cross-tenant replay and data exfiltration |
|
||||
| Evidence Pack and publication flow | manifest signature/verification, retention/immutability assumptions, artifact access control and chain of custody |
|
||||
| Production-like deployment | OIDC claim mapping, Vault/KMS access, Object Lock, rootless runner/sandbox, network egress and observability |
|
||||
|
||||
Out of scope tests require a written change order. Production data, destructive
|
||||
load tests, phishing and social engineering are forbidden unless the customer
|
||||
explicitly authorizes them in writing.
|
||||
|
||||
## 2. Prerequisites supplied by CASAN/customer
|
||||
|
||||
- A dedicated, non-production test tenant with synthetic code, prompts and
|
||||
secrets; no customer production source code or personal data.
|
||||
- DNS name, CA-issued test certificate, enterprise OIDC test application and
|
||||
least-privilege assessor accounts for viewer, operator, project-admin and
|
||||
org-admin roles.
|
||||
- A deployment inventory: image digests, SBOM, workflow commit, configuration
|
||||
version, data-flow diagram, network/egress policy and known limitations.
|
||||
- A change window, emergency contact, on-call escalation path and explicit
|
||||
stop-test authority.
|
||||
- A current Evidence Pack and commands for `verify-pack`, audit-chain
|
||||
verification, backup restore drill and release-provenance verification.
|
||||
|
||||
## 3. Required attack scenarios
|
||||
|
||||
The assessor must cover at least these scenario classes and record the exact
|
||||
target version/configuration for every finding:
|
||||
|
||||
1. Authentication/session handling, OIDC issuer/audience/JWKS failures and
|
||||
browser-supplied identity-header spoofing.
|
||||
2. RBAC scope escalation, separation-of-duties bypass and cross-project or
|
||||
cross-tenant reads/writes/replays.
|
||||
3. Prompt/tool-output injection, unregistered tool execution, CODEGEN write
|
||||
attempts and approval-token replay.
|
||||
4. Secret/PII exfiltration via logs, Evidence Pack, model routing, artifacts,
|
||||
API responses, error paths and egress configuration.
|
||||
5. Evidence/audit/trace tampering, clock/retention assumptions and failure of
|
||||
manifest/provenance verification.
|
||||
6. Container/sandbox privilege, rootful daemon usage, writable host mounts,
|
||||
network escape, resource exhaustion and queue starvation.
|
||||
7. Dependency, image and CI supply-chain validation against the live scanner,
|
||||
SBOM and digest/provenance assertions.
|
||||
|
||||
## 4. Rules of engagement
|
||||
|
||||
- Assessors must use named accounts and an agreed source-IP range; all activity
|
||||
is captured in the H5 audit trail and preserved in a review Evidence Pack.
|
||||
- Do not alter production state, delete artifacts, rotate real keys, or bypass
|
||||
legal/contractual third-party rate limits.
|
||||
- Critical findings trigger immediate notification to the security contact;
|
||||
CASAN may engage the kill switch while preserving evidence.
|
||||
- Retesting is required for every Critical/High finding and for any control
|
||||
used as an enterprise procurement claim.
|
||||
|
||||
## 5. Acceptance evidence
|
||||
|
||||
The independent assessor must deliver a dated, signed report with scope,
|
||||
methodology, target versions, findings/CVSS or agreed severity, reproduction
|
||||
evidence, limitations and retest results. CASAN must retain:
|
||||
|
||||
| Evidence | Owner |
|
||||
|---|---|
|
||||
| Signed statement of work and rules of engagement | Security owner |
|
||||
| Report plus finding/remediation register | Security + engineering owners |
|
||||
| Retest attestation for remediated findings | Assessor |
|
||||
| Evidence Pack and audit export for the assessment window | Release/security owner |
|
||||
| Risk acceptance signed by accountable business owner for any deferred finding | Customer/security owner |
|
||||
|
||||
Enterprise-pilot readiness requires no unresolved Critical findings. Any
|
||||
unresolved High finding needs a time-bounded, documented risk acceptance; this
|
||||
does not make the platform "pentest certified".
|
||||
Reference in New Issue
Block a user