• United States




Application security requires more talk than tech

Aug 18, 20163 mins
SecuritySoftware Development

Working with different departments to implement application security the right way

If you think application security only involves installing a tool, or scanning a few apps and moving on, you’re wrong. Application security is a unique security initiative, and its success hinges on people as much as technology.

 Employees don’t notice when you implement new anti-virus software. When you create a new firewall rule, it usually only impacts the network manager creating the rule. But application security is different. Because the application layer touches every part of the business and is constantly changing, you can’t just put up a wall or turn on a device to secure your apps. Rather, effective application security will require people in your organization to change their behaviors, their workflows, even their mindsets.

You’ll need to get buy-in from and consider the implications to multiple groups across your organization.


An AppSec initiative will stall before it starts if your dev team isn’t on board. It’s a must to work security into the earlier stages of development. But go-to-market strategies and competitive pressure often lead to hard deadlines that become developers’ sole priority — they want to avoid anything that might encumber their workflows.

Avoid the resistance by doing some homework on the development processes at your organization, studying the best ways to integrate security into those processes. Then get development and DevOps teams involved early during the planning phase. Approach the problem by giving them the power to influence the program’s protocols, making them vested partners in the project rather than recipients of a long list of rules. Getting development buy-in before the strategy launches lessens the chance of development teams ignoring security protocols and guidelines.

Executive team

You need executive buy-in to ensure your program gets the support and funding it needs. When you have the C-Suite’s ear, talk less about static and dynamic analysis and more about the bottom line. For instance, explain the risk that vulnerabilities in the application layer pose to an organization’s reputation and revenue streams. Leverage examples like TalkTalk, which lost about 100,000 customers and incurred about $130 million in costs and loss revenue due to breach. In addition, highlight how the assessment cycle will speed up development, as it reduces the cost of remediation post-production while streamlining go-to-market timelines.

Especially if you are embarking on a third-party application security program, strong buy-in and support from your legal team is key. Your legal department will help you craft language to make sure your vendor contracts are consistent with the security policies you want to enact. They will also evaluate whether your security demands are reasonable and enforceable. Conversely, the legal team will also help you craft language around your own security posture in situations where you are the software vendor.


This is probably not the first group that comes to mind when you think application security, but this group often purchases the most apps. Not to mention it can be an ally in promoting and communicating your AppSec program. In an effort to move quickly, marketing departments sometimes unwittingly circumvent security. When working with the marketing team, the most important thing you can do is to inform them of the risk and the policies you want to put into place. Then enlist their help in communicating your AppSec policy and its success.

 Ultimately, applications are thoroughly embedded into every part of your organization. You’ve got different people developing, assembling, updating, purchasing, uploading, selling and using apps constantly. In this light, securing them will take an equally diverse mix of people and an all-encompassing approach.


Chris Wysopal is CTO at Veracode, which he co-founded in 2006. He oversees technology strategy and information security. Prior to Veracode, Chris was vice president of research and development at security consultancy @Stake, which was acquired by Symantec.

In the 1990s, Chris was one of the original vulnerability researchers at The L0pht, a hacker think tank, where he was one of the first to publicize the risks of insecure software. He has testified before the U.S. Congress on the subjects of government security and how vulnerabilities are discovered in software.

Chris holds a bachelor of science degree in computer and systems engineering from Rensselaer Polytechnic Institute. He is the author of The Art of Software Security Testing.

The opinions expressed in this blog are those of Chris Wysopal and do not necessarily represent those of IDG Communications Inc. or its parent, subsidiary or affiliated companies.