Top 5 AppSec Missteps

In my three-plus years working with enterprise clients to help grow and mature their application security programs, I have seen the gamut of well-run programs and not-so-well run programs.  For the not-so-well-run programs, it is often the same reasons why the program is not successful and not reaching higher maturity levels.  The following are the top 5 mistakes I see most often:

1. No thoughtful risk ranking of applications

This is important because it can have negative downstream impacts.  Customers need to effectively rank their applications in terms of their business criticality.  Why is that?  Programs may have been allotted only a certain amount of budget, i.e. licenses, for AppSec.  If your program is only going to start with 20 applications, it makes sense that you would want to include your most critical applications first – like applications that have PII, or process credit card transactions, or are so important to the operation of the business that literally life or limb are at risk if the application is offline.  Also, knowing the business criticality of the application will ensure it is assigned the correct policy.  Taking care of this first is a good start for an AppSec program and will help to get things going in the right direction. 

2. Not using policy effectively

The policy contains the security requirements set by the security team.  It dictates what flaws should not be present in the application, and other testing requirements.  I see clients haphazardly assign policies in a way that is really not effective.  An example would be a program with 20 applications in scope being assigned 10 different policies.  There’s no reason even the largest programs should use more than a few policies.  Another mistake is having too stringent of a policy, especially for new programs.  Not only will this make your compliance rate look really bad, it will frustrate the development teams because their apps are not compliant and their delivery schedules are put at risk – not a great way to start a program.  Sometimes, organizations use policies that have rules that are not relevant.  For example, a program that is doing mainly static scanning shouldn’t have a policy with a dynamic scanning requirement.  Or a legacy app that has no active development shouldn’t have a requirement to do quarterly scanning.  This all sounds obvious, but we see these issues frequently.  So, make sure the policies make sense for what the program is trying to achieve, and make sure the difficulty of the policy is in line with the maturity of the program. 

3. Not sharing the right metrics with leadership

Metrics and numbers are plentiful in the land of application security.  There are a million different metrics that we provide to our clients.  But what are the ones that are important, a KPI that a CIO or CISO would be interested in? We recommend reporting up the total number of apps in program, alongside the percentage of apps in compliance with your AppSec policy. Measuring policy compliance over time is a great way to observe the efficacy of the program.  If it’s increasing over time, as a successful program should be, it indicates more applications are becoming compliant and risk is being removed from applications.  If it’s flat or even decreasing over time, this will help to highlight a struggling program, or it’s possible that there were issues with the items mentioned in #1 and #2.  Establish the important KPIs up front.  This will help to spotlight program success or failure, and help to get a program in either situation more attention and more funding. 

4. Not including developers in the planning process

If your internal development teams are not aware of the expectations for what’s required to secure their applications, how are they going to be successful?  This goes beyond just telling them what they need to do.  Work to create security champions who can be security advocates on the development team and ensure that security works with existing development processes. In addition, create an internal AppSec website that you can use to share information to all program stakeholders.  If there is an internal security mandate from the office of the CISO, share it here for all to see.  Use the site to distribute relevant security articles, blogs, timely events, and training initiatives; make it interactive to further foster two-way communication.  Effectively communicating the goals of the program will not only keep everybody in synch, but it will also help to nurture the ever-important relationship between development and security. 

5. Trying to go it alone

A successful application security program is a partnership between the organization and its application security vendor.  Each brings a level of expertise to make sure things run smoothly and efficiently.  Here at Veracode, we have a strong foundation of experience and resources to provide the guidance to make programs successful.  We have developed a playbook of best practices to help make sure the program stays on track.  But our security and developer customers are intelligent, resourceful, can figure things out on their own, and often don’t think they need outside guidance. However, with the security skills gap, trying to manage a program 100 percent internally will not yield optimal results. We supplement our customers’ activities by helping to onboard development teams, helping the security team get things set up administratively so users get the access they need, and providing guidance on setting up the policy, interpreting results, and remediation next steps. 

The good news is that you can easily address these issues, even for AppSec programs that are already up and running.  Avoid these mistakes from the start, and application security at your organization has a great chance to achieve success!

For more details on managing and maturing an application security program, check out our guide, From Ad Hoc to Advanced Application Security: Your Path to a Mature AppSec Program.