We’ve been in the application security business for more than 10 years, and we’ve learned a lot in that time about what works, and what doesn’t. This is the fifth in a blog series that takes a look at some of the most common mistakes we see that lead to failed AppSec initiatives. Use our experience to make sure you avoid these mistakes and set yourself up for application security success.
Application security is about more than tools and technology. It is just as much, if not more so, about people. In particular, if you don’t have buy in from your development and executive teams – your AppSec program will stall before it starts. An application security initiative will affect developers’ everyday lives more than anyone else at your organization. In turn, if you neglect to get developer feedback and input early in the planning process, you’ll create more resentment and conflict than secure code. Without executive buy-in to your application security plans and goals, you’ll have a tough time getting the rest of the organization on board, and most likely an impossible time getting the funding you need to grow and mature your program.
To ensure the success of your application security initiative, it’s essential to work closely with your developers so they understand the guidelines, strategies, policies, procedures, and security risks involved with application security. What’s more, they must be prepared and equipped to operate securely within their particular software development processes.
Ryan O’Boyle, product security architect at Veracode, recently recorded a quick “chalkboard” video where he outlines our top 5 ways to get developer application security buy-in. These include the following:
Way No. 1: Timing: Bring in developers early in the planning process. Start with the following questions: Can you describe our software development lifecycle? When do you currently assess the applications you are building for security? How often are they tested? Where do you think security assessments belong in the lifecycle? How can we best fit into your existing process? What are your biggest concerns about starting a program? What would be the best way to test our strategy once we agree on the process?
Way No. 2: Understanding: Learn about developers’ priorities and processes. To embed security into developers’ workflows, you need a deeper understanding of development processes, tools and priorities.
Way No. 3: Training: Most developers have had no training on secure coding practices. Set your developers up for success. Make sure they have the know-how to fix what they find.
Way No. 4: Integrating: Work to integrate application security into existing developer tools and processes. Make it as easy as possible for developers to conduct security testing.
Way No. 5: Automating: Build tests into the pipeline through automation. Again, you’ll avoid pushback if you consider developers’ pains and priorities and make security testing fit into their workflows as seamlessly as possible.
When working with the C-suite around application security, the key is to focus on the benefits to the organization, rather than the technology or technical details of the program.
Provide information around how the assessment cycle will speed up development and reduce the cost of remediating vulnerabilities post-production. The conversation should also include information about the risk that vulnerabilities in the application layer pose to the organization, and how reducing this risk will ultimately save the company money and time.
Be prepared to answer the following questions: What does our risk posture look like now? Why should we invest in application security as opposed to other forms of cybersecurity? What metrics will you use to demonstrate progress?
Don’t repeat the mistakes of the past; learn from other organizations and avoid the most common AppSec pitfalls. Today’s tip: Get your developers and execs involved with your AppSec program early – in the planning phase. Get details on all six of the most popular mistakes in our eBook, AppSec: What Not to Do.