Thirty-one random #AppSec Thoughts

Over October 2022, for NCSAM, I shared thirty-one random AppSec thoughts. For some of these thoughts, I’ve pointed to other writings I’ve prepared covering the topics more in-depth.

1. Shift left and shift right = Secure Development Lifecycle. What’s old is new again.
   • Read more — Secure Development Lifecycle: The essential guide to safe software pipelines
2. With all the attention on API security, we often overlook the OWASP API Security Top Ten.
   • Read more — OWASP API Security Top 10: Get your dev team up to speed.
3. The OWASP Proactive Controls is the answer to how to fix/avoid the issues of the OWASP Top Ten.
   • Read more — OWASP Proactive Controls: the answer to the OWASP Top Ten
4. #ThreatModeling is analyzing representations of a system, to uncover the security and privacy challenges that exist.
   • Read more — The best threat modeling representation
5. Why do we have so many 4-letter acronyms in #AppSec? SAST, DAST, IAST, and RASP, oh my!
6. Security culture is measured by what your developers do with a security problem when nobody is looking.
   • Read more — 6 ways to develop a security culture from top to bottom
7. Security champions are a force multiplier for your security team.
   • Read more — Information security needs community: 6 ways to build up your teams
8. Imagine a future where all developers are security enlightened.
9. Everyone is a security person — no matter your functional role within the organization, you own a piece of the security solution.
10. Security culture eats strategy for breakfast.
11. People, process, tools, and GOVERNANCE. Governance is the piece that everyone always forgets.
12. Security should never be a gatekeeper — security should open doors, not shut them.
    • Read more — Why developers dislike security—and what you can do about it
13. Regardless of how much effort you put into breaking, security is no better until the builders engage.
14. OWASP is a treasure trove of security resources.
    • Read more — How to do application security on a budget
15. Break the build for vulnerable open source and third-party, but provide a filtering mechanism to allow builds to progress when there is no known fix.
16. Shift {left, right, outwards} – just start.
17. The Sec in #DevOps is silent.
18. GitHub is a terrible place to store secrets.
19. Teach the developers the underlying principles of the tools, and then watch how the tools magnify #AppSec.
20. Security requires the ability to sell and market. The best security people can explain their idea well, share the value prop, and communicate.
21. Developers take pride in their craft — they want to create more secure code — you must show them the way.
22. Pipelines are the best way to represent a #DevSecOps build pipeline.
23. Developers must understand all the component pieces of the build pipeline. Developers are smart — they’ll provide feedback on those pieces and help tune the tools.
24. Launching a new security tool does not mean we enable every policy — increasing the fidelity of the security tool results in developer buy-in.
25. Security people must learn how to code. The resources on the Internet are vast, and the excuses for why you don’t need to code are few.
26. The DevSecOps Maturity Model (DSOMM) is an assessment tool for your DevSecOps and a builder of roadmaps.
27. As a security professional, drop the no; try “yes, if.” Be a partner and not a roadblock.
28. Threat modeling uncovers design-related issues, and the best threat modeling tool is the human brain.
29. Guard rails are a better strategy than roadblocks. Provide limits, and encourage creativity within the boundaries.
30. At the end of the day, #AppSec is a people-based solution, with support from the process and the tools.
31. We have too many data streams in an #AppSec program; look for tools to correlate and consolidate the streams into developer-usable results.