Goal of SDLC
Security can no longer be “outsourced” to the security team, but rather that the security team’s mission changes to providing the resources for teams to be security self-sufficient
SDLC Component and phases
- Developer Training
- Threat Modeling
- Design Reviews
- Static Analysis
- Run static code analysis on the codebase for known code-level security vulnerabilities
- Here is a list of scanners from OWASP to choose from, and some other ones
- Identify specific classes of vulnerabilities you care about most, and start with just those
- Focus on eliminating false positives and enabling velocity with the goal of only producing real issues that can be directly consumed by a developer themselves
-
Once completed, add one or two more vulnerabilities classes
Examples:
- Rather than trying to start with static analysis for XSS, SQLi, Directory Traversal, Command Execution, etc all at once, pick one (system)
- Identify use of certain primitives that should initiate a conversation with the security team rather than just be blocked (encryption)
- Keep dependencies up to date (requires.io)
- Run automated dependency scanners to check that we are using the latest, most secure version of our code dependencies
- It can be a pain to keep things up-to-date, but OWASP is a lifesaver
- Dynamic Scanning
- Spin up the service and attached resources in a pseudo test mode and point automated penetration bots at the running containers and see what happens
- If the scanners come back with warnings, then we reject the build
- A great tool that makes this possible is zaproxy
- Ensuring that security policies are being enforced (TLS ciphers)
- Ensuring previous vulnerabilities aren’t accidentally regressed back in to the application (we had an XSS in this parameter before, always check it with this specific payload to ensure the protection didn’t get accidentally rolled back)
- Pentesting
- Security Visibility
- Feedback
Sources: