As an engineering manager, I am challenged to keep pace with ever-expanding expectations for non-functional software requirements. One requirement, application security, has become increasingly critical in recent years, posing new challenges for software engineering teams.
In what manner has security emerged as an application requirement? Are software teams equipped to respond? What can engineering managers do to ensure their teams build secure software applications?
In the '90s, security was not a visible software requirement. During this time I worked with a team developing an innovative web content management system. We focused on scalability and performance, ensuring that dynamically generated web pages rendered quickly and scaled as the web audience grew. I don't remember any security requirements nor any conversations about application security. Scary, but true! Our system was deployed by early-adopter media companies racing to deliver real-time online content. IT teams deploying our system may have considered security, but if they did, they focused on infrastructure and didn't address security with us, their software vendor.
Ten years later, application security requirements began emerging in a limited way, focusing on compliance and process. At the time, I was working at a startup, developing software for financial institutions to uncover fraud through analysis of sensitive financial, customer and employee data. We routinely responded to requests for proposal (RFPs) with security questions about the controls to prevent my company's employees from stealing data. We described our rigorous release, deployment and services processes. Without much ado, and without changes to our development process, our team simply "checked the box" for security.
A few years later the stakes became higher. New questions began showing up in RFPs: "How does your software architecture support security?" "How do your engineering practices enforce security?" And the most difficult to answer: "Provide independent attestation that your software is secure."
I faced a sobering realization. The security of our software relied entirely on the technical acumen of our engineering leads (which fortunately was strong), and was not supported in a formal way in the engineering process. Even worse, I was starting from scratch to learn security basics. I needed help, and fast!
Engineering leads at small independent software vendors (ISVs), such as NSFOCUS and Questionmark, face this challenge routinely. Where should they start? What concrete steps can they take to secure their code and establish a process for application security?
Pete Chestna recently posted "Four Steps to Successfully Implementing Security into a Continuous Development Shop." His approach has worked for us at Veracode and translates well to small and large engineering teams:
- Learn, hire or consult with experts to understand the threat landscape for your software. Develop an application-security policy aligned with your risk profile.
- Baseline the security of your application. Review and prioritize the issues according to your policy.
- Educate your developers on security fundamentals and assign them to fix and remediate issues.
- Update your software development life cycle (SDLC) to embed security practices so that new software is developed securely.
You will need budget and time to accomplish this. Consult with experts or engage with security services such as Veracode to benefit from their experience and expertise.
Don't try to wing it. The stakes are too high.