Goal
Security is a requirement, not decoration: verify against a checklist, scan automatically, never leak secrets, and handle personal data lawfully.
Inputs → outputs
Inputs
- Threat model and SDD
- Staging build
- Client compliance requirements
Deliverables
- Completed ASVS checklist + evidence
- Scan reports & remediation list
- Secrets & access policy
- Personal-data impact assessment (if applicable)
Teams & roles
- Application Security (AppSec)security review, ASVS, scans, DAST
- Engineering (FE · BE · Mobile)fixes findings
- DevOps / SREsecrets management, CI scanning
- Infrastructure & Networkleast privilege on infrastructure
- Legal & Financepersonal-data compliance
- Client (Product Owner / sponsor)states compliance needs, keeps root accounts
RACI matrix
R — does the work · A — accountable, final sign-off (exactly one A per activity) · C — consulted before · I — informed after.
| Activity | Dev | QA | Sec | Ops | Infra | Legal | Client |
|---|---|---|---|---|---|---|---|
| Security code review | R | · | A | · | · | · | · |
| SCA / SAST in CI | C | · | A | R | · | · | · |
| Verify against OWASP ASVS | C | R | A | · | · | · | · |
| Secrets & least privilege | · | · | C | A | R | · | · |
| DAST on staging | · | C | A | · | · | · | · |
| Personal-data impact assessment | · | · | R | · | · | A | C |
Dev = Engineering (FE · BE · Mobile); QA = Quality Assurance (QA/QC); Sec = Application Security (AppSec); Ops = DevOps / SRE; Infra = Infrastructure & Network; Legal = Legal & Finance; Client = Client (Product Owner / sponsor)
Quality gate
No high-severity findings; all secrets outside the repo.
Entry criteria
- Main features running on staging
- Threat model updated to the current design
Exit criteria
- No open Critical/High findings, or written risk acceptance
- ASVS checklist at the agreed level completed with evidence
- No secrets in git history
- No critical dependency CVEs that already have a fix
- Personal-data impact assessment prepared (if applicable)
Activities
- 1.Security-focused code review: authn, authz, input, uploads
- 2.Dependency (SCA) and static (SAST) scans in CI
- 3.Verify against OWASP ASVS at a fitting level (usually L1–L2)
- 4.Secrets management: nothing in git, key rotation, least privilege
- 5.Dynamic scan (DAST) on staging before go-live
- 6.Personal-data processing impact assessment when the system handles personal data
Checklist
Tick to self-review — 0/6. Ticks stay in this browser only and are not sent anywhere.
Document templates
Markdown (.md) files: open in any editor, or paste into Word / Google Docs. Each states its purpose, who fills it in and when.
Client involvement
- State compliance needs (personal data, payments…)
- Keep ownership of root accounts for all services
- Sign a written risk acceptance for any unresolved finding
Tools
- npm audit / Dependabot
- Semgrep
- gitleaks
- Trivy
- OWASP ZAP
Reference standards
- OWASP ASVS 5.0
- Application Security Verification Standard
- OWASP Top 10
- Most common web application risks
- NIST SP 800-218 (SSDF)
- Secure Software Development Framework
- CWE Top 25
- Most dangerous software weaknesses
- Luật Bảo vệ dữ liệu cá nhân 2025 (91/2025/QH15) và Nghị định 356/2025/NĐ-CP
- Protection measures and personal-data processing impact assessment
Common pitfalls
- Hiding a button in the UI without blocking the API
- Third-party API keys shipped in browser code
- Scanning once before go-live and never again
- Accepting risk verbally
Real example
cuongthai.com: third-party API keys never go intoNEXT_PUBLIC_*variables (they get baked into browser JavaScript) — every third-party service goes through an authenticated backend proxy route. SSH is key-only; disabling password login was verified withsshd -T(the effective value), not by re-reading the file just written.
Where to learn
Subjects and courses on cuongthai.com that teach this stage’s work.