Secure Development Lifecycle and Incident Response
Build security into every stage
| Stage | Practice |
|---|---|
| Design | threat model new features: what could go wrong, who would attack, what is valuable |
| Code | secure defaults, framework protections, peer review with a security checklist |
| Test | permission matrix tests, SAST/SCA in CI, dynamic scans on staging |
| Deploy | secrets management, least-privilege infrastructure, security headers |
| Operate | logging, monitoring, patching, backups, incident response plan |
Lightweight threat modelling
For a new feature, spend 20 minutes on four questions:
- What are we building? (a quick data-flow sketch)
- What can go wrong? (use STRIDE: spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege)
- What are we doing about it?
- Did we do a good job? (tests, review)
Logging and monitoring
Log security events: logins and failures, MFA changes, password resets, permission denials, admin actions, payment events. Include who, what, when and from where; never passwords, tokens or full card data. Alert on spikes in failures, new admin accounts and unusual access patterns.
Incident response
When you suspect a breach:
- Contain: revoke compromised credentials and keys, disable affected accounts or features.
- Preserve evidence: keep logs and snapshots before changing too much.
- Investigate: what happened, when, what data was affected.
- Eradicate and recover: fix the vulnerability, restore from clean backups if needed.
- Notify: affected users and, where required by law, regulators within the legal timeframe.
- Learn: a blameless post-mortem and changes to prevent recurrence.
Write this plan down before you need it, with contacts and steps.
Responsible disclosure
Publish a security.txt file (/.well-known/security.txt) with a contact address so researchers can report issues to you. Respond quickly, fix promptly and thank reporters.
Final project
Perform an authorised security review of your own application: threat-model two features, run SAST, dependency and dynamic scans, build an access-control test matrix, fix the findings with regression tests, add security headers and a CSP, publish security.txt and write an incident response plan. Present the results as a short report with severity ratings, as you would for a client.
Check yourself
- What are the four threat-modelling questions?
- What must security logs never contain?
- What is the first step when you suspect a breach?
I tuoi progressi sono salvati solo in questo browser.
Invia per la revisione (10 punti)