3 ways an appsec program saves time for developers

During WWII, the leaders of the three Allies (Stalin, Roosevelt, Churchill), were three very different men with vastly different ideologies. Yet, they needed to work together in order to achieve a common goal: defeat the Axis powers. Can you imagine the tension this must have created?

Security, development and operations professionals face a similar dilemma; their ideologies differ, yet they must work together to thwart a common enemy: cyberattackers. And while security professionals, developers, and IT operations personnel aren’t exactly waging a war against fascism, the threat their foes present are no less critical to our economic and physical safety.

The conflicting goals that arise from quickly producing and releasing software while managing the risk software vulnerabilities introduce into an enterprise create a tension between developers and security teams. Developers are under intense pressure to release software and updates fast. Their primary goal is functional code that satisfies customer requirements. Security requirements, however, become barriers to achieve this goal — or so developers assume.

Typically, security is an afterthought that causes developers to re-write completed and functional code just as the application is ready to ship. In a developer’s mind, this is wasted time and effort and is cause for frustration. Instead, security should be made into early prevention rather than late stage testing and remediation.

The problem is security professionals rarely consult their development teams when creating an application security program. By working closely with developers to understand their workflows and processes, security professionals can ensure that security testing is done at the stage of development that is most optimal for their development teams. And by understanding the tools developers use, security professionals can automate and integrate security testing at a automation level. When this is accomplished and a well-planned and executed AppSec program is in place, it can actually save developers time, maintaining productivity without sacrificing security.

Find vulnerabilities sooner

One of the reasons developers view security requirements as detrimental to their release cycles is that typically security has been bolted on as a last-minute requirement. Just as an application is ready to go out the door, the security team swoops in with a list of required fixes forcing the development team to spend time they don’t have remediating vulnerabilities.

But if security assessments are integrated into the development processes from the start, this pitfall is completely avoided. Remediation and mitigation become part of the normal development cycle and by the time the solution is complete, it’s secure.

Some would argue that the introduction of security requirements will slow down DevOps and continuous release cycles, but the opposite is likely true. When you are making incremental updates, you are making smaller changes, meaning quicker assessments of smaller portions of the code turning testing and remediation into prevention.

Beyond the development lifecycle

A strong application security program looks at the entire picture of an applications lifecycle — not just the development phase, but also into deployment and monitoring. By working with the development team to better understand the full application lifecycle, security professionals are better equipped to create a security program that works with developers instead of against them. This alleviates the tension as the development processes is less disrupted, while maintaining high standards of security.

For example, instead of relying solely on assessments during the development process, companies with advanced application security programs are able to protect applications in production so applications already in production are protected from attacks. This allows enterprises to prioritize remediation activities.

Practice makes perfect

One of the paradoxes of a strong application security program is that the more security is integrated into the software development lifecycle, the lower the flaw density becomes over time. Why is this so? It is because developers end up learning from past experience and avoid introducing vulnerabilities to begin with.

Demonstrating to developers where they are introducing vulnerabilities into their code can cause a negative reaction. Developers feel shamed for writing “bad” code, and this feeling of shame can only increase tension between those that are frustrated (developers) and those that are pointing out the flaws (security). When security testing is made self-service and an individual developer process there is no feeling of an auditor overseeing a developer’s work. The developer has an opportunity to correct flaws without oversight much like he or she is used to fixing a syntax error.

However, application security should not focus solely on pointing out flaws. It should also educate developers with best practices for secure coding, and congratulate them on improvements.   If it becomes possible to provide positive feedback on where developers are using the secure coding practices they are learning, developers are more apt to avoid mistakes in the future, reducing security related defects in software early in the development processes.

Working together and providing positive feedback will also release some of the tension between security and development. Instead of feeling shamed, developers will feel empowered, and they will be able to write more secure code without the need for as much security intervention.

As developers continue to face increasing pressures to produce and release more software faster than ever, the tension between developers and security professionals will only intensify. That is of course, unless each team focuses on their shared goals and the desired outcomes.

Just as Stalin, Churchill and Roosevelt were not best friends, security, development, and operations teams may never see eye-to-eye on security vs. speed. Yet there doesn’t have to be intense tension between the groups. They are fighting against a common foe, and if the teams work together, security can be an enabler of producing high-quality, functional and secure code.