Software development project stakeholders can often be tempted to put security requirements on the back burner when developing software systems. During one particular large-scale software development project I was involved with, which was a distributed system consisting of many components communicating over the network, runtime performance was the most important quality attribute. The engineers brilliantly invented their own lightweight protocol to maximize runtime performance. Once the system was to be transitioned into production operations, it was discovered that encryption and authentication had to be added to comply with the security requirements of the customer's site. These changes resulted in degraded runtime performance and delayed the system's ability to be used in the field. The project went over schedule, and costly rework had to be performed to accommodate the added overhead of secure communications. In this blog post, I will explore rethinking software requirements to maximize security and minimize risk.

In many organizations, software application security assurance involves performing security reviews, static code analysis, and penetration testing on a piece of software at the end of its development phase, before it is released to production. Remediating security-related findings at the end of the software development lifecycle can lead to suboptimal outcomes in the form of degraded application performance or failed regression tests, requiring costly rework and delay.

Moreover, a large portion of IT security depends on border defense, where as long as an application lives inside a protected network, the security of that application is not a first concern. The concept of border security is as old as human civilization where ancient peoples resided in walled fortresses designed to keep attackers at bay. In cyber terms, system architects draw and protect a perimeter around trusted networks and assets expecting that this keeps safe all systems inside. The downfall of this approach is when something catastrophic happens, such as clicking a phishing link and exposing protected assets. Once an attacker breaks the perimeter, it may be too late to avoid damage. This weakness underscores the need for organizations to focus on building secure systems that are assumed to be eventually attacked. How can this best be achieved?

DevOps Principles to the Rescue

DevOps luminaries often talk about shifting left operational concerns. Shifting left means that instead of engaging IT operations teams late in the game (e.g., the night a software change is scheduled to move into production), these engagements happen early in the lifecycle. Shifting left is enabled by early collaboration and enforced through infrastructure as code and continuous integration and continuous delivery. This practice exposes issues and challenges as early as possible, which leads to better outcomes if managed properly.

In the same way that operational concerns shift left, application security can also shift left. Application security engineers should be brought into project teams during the requirements gathering phase to help discover and define security requirements. After these requirements are defined, the outcome of the initial sprints of an effort should result in a secure "Hello World" application. With this approach, the security requirements of the application are met before any functional requirements are met. The secure "Hello World" application's development pipeline should be outfitted with the tooling required to monitor third-party libraries and dependencies for vulnerabilities, perform automated static code analysis, have automated penetration testing, assure that security-focused peer reviews take place, and assure proper threat models have been constructed and mitigations extracted in the form of security requirements.

Business stakeholders naturally want to see the functionality they asked for early in the software development lifecycle because these are the visible and seemingly most important aspects of the software under construction. It may take the support of leadership to enable the creation of a secure "Hello World" application because it may be counter-intuitive to the customers to focus on security first. As organizations mature, these secure "Hello World" applications can be templated to minimize the up-front costs of creating them.

Application security assurance activities do not end with the successful completion of the secure "Hello World." As new features are added that change the security posture of the application, new security assessments must be performed and new security tests must be devised to cover new aspects of the system. The key is to implement application security and verify the application's quality early to minimize impact.

Wrapping Up and Looking Ahead

Like many things in modern software development, what's best for a given organization or team is context-sensitive, depending on the specific use case, the customer, the technical team, and the important quality attributes. New practices should be tested, measured, and only employed where they make sense.

Security is best baked into an application from the beginning, not applied at the end of its development. Security requirements should be elevated to first-class citizens of the requirements document of an application to the extent that the application should not go far past the "Hello World" phase until security requirements are met.

Additional Resources

To view the webinar DevOps Panel Discussion featuring Kevin Fall, Hasan Yasar, and Joseph D. Yankel, please click here.

To view the webinar Culture Shock: Unlocking DevOps with Collaboration and Communication with Aaron Volkmann and Todd Waits please click here.

To view the webinar What DevOps is Not! with Hasan Yasar and C. Aaron Cois, please click here.

To listen to the podcast DevOps--Transform Development and Operations for Fast, Secure Deployments featuring Gene Kim and Julia Allen, please click here.

To read all of the blog posts in our DevOps series, please click here.