As someone who's used a LOT of AppSec tools over the years, I wanted to share how I help clients select their AppSec tools, so I've drafted a simple framework to guide you in finding the ideal match for your security needs. There is no one tool that is perfect for every organization, and if you have the wrong one it can create friction, delays, frustration, and lack of adoption. I use the questions below to help create a set of requirements for clients, and then they go shopping!
Step 1: Crowdsource like a pro
Reach out to your buddies, pals, and colleagues in the industry. Ask them about their tool experiences—what they adore, despise, and why. It's like picking a movie based on your friends' reviews; you want that real-world feedback! You should also use your fav search engine to check what people say about it on various forums, strangers opinions can be helpful too!
Step 2: First or second generation?
Decide if you prefer a first generation (symbolic execution + flow analysis) or second generation (anti-pattern matching + flow analysis) static analysis tool. Do you want to invest a lot of time into each and every application to ensure they are absolutely perfect (first gen)? Or do you need to move fast, have great-but-not-quite-perfect security, and look at many apps very quickly (second gen)? Do you plan to fix 100% of what you find and dedicate weeks to secure each app (first gen)? Or do you want to release 10 times a week and can’t wait for manual validation of every result (second gen)? Decide if you prefer first or second generation SAST and this will narrow down your scope a lot!
Step 3: Compatibility check
Ensure the tool supports all the languages and frameworks your team uses. If the SAST doesn’t support the languages your team uses, you would need more than one tool, and that’s probably something you want to avoid (to save time, money, learning, and more!).
Step 4: Truly homemade apps
Do you have a custom, in-house created framework that your company uses for everything? If it's not open source, finding a tool SAST that speaks its language might be a challenge. Take this into consideration when you choose a tool, as you will need to write a lot of your own rules!
Step 5: Integration ease
Can the tool integrate nicely with your current system and tools? Think of it like choosing someone to travel with—will they adapt to your style or be a hassle at every turn? Can the SAST integrate with your IDE? Your code repository? Your cloud? If it can’t, maybe it’s not the right one for you and your team.
Step 6: Server management overhead
Are you ready to be the tool’s server caretaker? It's like adopting a virtual pet—you'll need to feed and water it regularly. Are you up for the responsibility? If not, then choose a SAST with a SaaS offering.
Step 7: Source code secrets
Ready to open the vault and share access to your source code with the vendor? It's like inviting someone over for a peek at your messy office. Each vendor is different, and several of them will want access to your source code in order for their tool to function properly. Make sure your policy allows that!
Step 8: Financial Fit
Can you afford the tool without breaking the bank? Calculate what you're willing to invest—it's like budgeting for a gourmet meal versus a food truck. Choose wisely!
Step 9: Tailor-made tool
Is the tool customizable to suit your environment like a handmade suit? If it’s inflexible, and your team like’s to customize, it could be a bad fit. Get requirements from your developers in advance to help you figure out what you need to ask for.
Step 10: Creating your own rulebook
Does the tool let you create your own SAST rules? You might need to tailor the tests and results to your organization's unique challenges, risks, and needs. If this is important to you, make sure you can call the shots!
Step 11: Proof of concept
The most important step! Get your software developers to try out the tool with you, before you buy. They are the ones who will likely be affected by the tool the most, and their buy-in is essential for it to be a successful rollout. It’s very important you set up the tool, with all your systems (at least one IDE, your CI, one app, and hopefully a few developers), and then try it out. Does it work how the sales person said it would? Do the developers love it or hate it? Let them help you make the final decision.
By following these steps and considerations, you'll be equipped to select a static analysis tool that's not just good but hopefully the perfect match for your organization. If you choose carefully, the tool will help you create more secure code, faster, and with less friction between the teams! Go forth and choose your next tool with confidence!
