Checkmarx Named a Leader in Gartner Magic Quadrant for Application Security Testing

Application Security Testing: 7 Steps to a Recipe for Success

Security tools are becoming more and more popular throughout the world of tech, and for security enthusiasts, and it should be something to celebrate about. But, in reality, we still have a long way to go when it comes to the actual use of the tools.

We’ve known for years about the major gap between security and development, and we’re getting better. But while the proliferation of the DevOps movement has made organizations realize that security is essential to agile processes, we’re still missing a piece of the puzzle. Because while the purchase of security solutions might be increasing, developer use isn’t quite on par.


A recent study by North Carolina State University confirmed the problem, finding that even developers involved in designing secure applications will circumvent security policies if security isn’t being enforced and the security team isn’t engaging them. This even includes apps used in hospitals and similar high-risk industries, making the situation alarming, perhaps, but there was a silver-lining that the researchers found.


The research team found that “the two things that were most strongly associated with using security tools were peer influence and corporate culture.”


While it’s great news that the market for application security tools is increasing, we need to work on improving actual use by developers. When it comes to security and the looming risks if the tools we’ve purchased aren’t put to correct use, it’s time to make sure we’re making the most out of them – or risk putting your organization on the line.


So, on that note, let’s take a look at some steps you can take to improve your chances at having your security tools actually used.


  • Educate your developers and empower them to use the tool


Who else, besides you and your security team will be using your SAST tool? If you have a secure SDLC in place (and we’ll get to that step later), then your developers will most likely be participating in – if not in charge of – security testing. Yet, like the SANS Institute State of Application Security Report found this year, many developers are inexperienced with security protocols and correct security testing procedures.


If you want them to buy-in to the tool – and you need them to get on board with it – the first step to getting them to use it is to teach them correctly from the start. The tool itself needs to be understood by the development team or it won’t get used. Plus, empowering developers to be in charge of security procedures can help ease the tension between your teams.


In the NC State study, the researchers found that “respondents who used security tools were more likely to report they felt personally responsible for the security of the software they develop.” Even better news, the same survey respondents reported they communicated more with the security team to help improve the process.


That starts with proper training for the tool and continued support as they do security testing on their own. Online training is always a great option, but make sure the lessons are relevant and at their skill levels – and choose an option that will keep developers interested. Ensure that the high-risk vulnerabilities you want developers to avoid and look for in testing are incorporated in lessons.


Game of Hacks: Putting the Fun in Security Fundamentals

Keeping developers engaged with security necessitates some creativity and definitely some fun so be prepared to offer incentives, whether it’s setting up a CTF or doing a trivia night (or daytime program, to keep on their good sides) surrounding security issues – and we definitely recommend introducing your developers to Game of Hacks!


Developer education when it comes to security testing is not a one-and-done deal. It’s important to have some kind of continued education, because they need to know about the latest threats that they should be on the lookout for, any vulnerabilities that stand out in reports as something that needs to be addressed, etc. Getting developers involved in local OWASP activities is a great way to engage them in interesting activities around security.


  • Find ‘AppSec Champions’ on development teams


Building on the above tip, another key to getting the maximum out of security testing is to appoint developers that seem engaged in the security aspect as “security champions.” Get them involved in more application security activities, such as threat modeling, collaborating with architects on building security into new features, and asking for their opinions and feedback on your AppSec program. Further, as the PCI Security Standards Council advises, assign them with ensuring that your security policies and procedures are being followed and help keep them up-to-date on the latest security threats.


As Robb Reck pointed out in his RSA talk this past spring (slide deck here), creating security champions helps keeps the program on track, even when you’re working on something else. By collaborating with the department managers to get security work recognized in employee review processes, developers will want to get involved. Handing responsibility over to developers, who are the ones most familiar with your organization’s code – as well as the ones who actually use the tools implemented by the security team – is a win-win.


  • Get support across the board


The NC State survey found that management support was a big encourager for tool use with developers. So even before a tool is purchased, it’s crucial that you clearly articulate your goals for the tool and your expectations for management and ask them for their support in your plan for its implementation.


Introducing a new security tool can be met with resistance from all angles, but getting stakeholders on board with your new tool or tool set is going to be essential for its success when testing applications. Have discussions with executives as well as department managers and explaining the benefits your security tool will have for each of their “bottom lines,” and ask for their input on how to make the security tool run smoothest wherever it’s to be used.


The support will help establish a stronger security culture throughout your organization, and push your developers to feel more responsibility toward their own code security.


  • Integrate SAST Testing throughout the SDLC


NIST cost to fixAs James Kaplan, co-author of a book on protecting organizations from security threats and a partner at Mckinsey & Co. was quoted saying, “A far better model (for software development) would be if you were teaching your developers how to write secure code, were including security architects in the development process from day one of the project, and investing in tools for secure development. Then you have many fewer flaws at the end of the process.”


The best way of getting the maximum ROI of your tool is by implementing it at every point in your organization’s SDLC where other testing is currently done. By introducing security in those milestone checks, security bugs can be found sooner and fixes can be made in a much more cost-effective manner.


The integrity of your applications depends on security being done right and not holding down the line at any point of the process. That’s what makes a good static code analysis tool perfect for the job of integrating into your SDLC:


But this tip goes for all application security tools. The best defense is always going to be a defense in depth – a mix of testing methods that well-suits your needs in regards to organization and the software you’re developing. Any tool you use needs to be implemented well into your organization.


  • Fine tune your rules to your code


Filtering out the extra noise that comes with any new security tool is another essential part of achieving success with your application security testing tool. First of all, ensure that your tool is fit for your programming languages. More importantly, though, remember that there will be work to do in the beginning filtering out the noise, if you find false positives, and, if your tool allows for it, adding custom queries fit to your specific policies and needs.


Also, when training developers in security, ensure they are taught how to look for false positives and negatives themselves, and encourage them to engage with either their ‘appointed’ security champion or a member of the security team if they’re not sure. Having more eyes trained to be on the lookout for potential issues will help propel your security program forward.


  • Use automation to your advantage


Automation offers some pretty amazing advantages. You want to use your security and development teams to their full potential. But less-than-stimulating tasks like identifying issues and where to fix them in the code along with building reports of the issues they found can prevent that from happening. And as your organization grows, even with bigger teams, these are activities that can cost huge in terms of both time and man hours. That’s where automation can make a big difference, especially when it comes to scaling security practices.


By automating processes like setting your security tool to scan code at every code check-in so developer have a report and fix suggestions waiting for them almost immediately or indicating to developers the best place to fix a vulnerability, you’re helping set the stage for success. Especially in agile environment, developers will be much more at ease with a tool that doesn’t force them to work harder than they already do – and you’ll have more peace of mind that your program is running smoothly.  


Automation isn’t for every part of the process, and we’re not advocating you to side-step additional security practices, such as manual checks done on especially sensitive parts of your code. But there are points in your SDLC that can alleviate some of the major pains that come with introducing security into the process.


  • Analyze and evolve continuously


Just like providing security awareness for developers is a continuous process, so is analyzing how your security tools are being used and revising your policies and procedures accordingly. You may think you know exactly how a tool is going to be used, but in reality it will probably look much different than you planned.


First, it’s important to introduce a tool gradually throughout the organization, and modify it as you continue to see fit. It’s also essential to be open to changes, especially as your organization evolves and more code is developed. You want your program to be successful, and your security solutions are an essential part of it. And that means making sure the ones using it are satisfied and making adjustments as needed.

Jump to Category