Shift Left on Security

Security is everyone's responsibility and by better integrating information security (InfoSec) objectives into daily work, teams can achieve higher levels of software delivery performance and build more secure systems. This idea is also known as shifting left, because concerns, including security concerns, are addressed earlier in the software development lifecycle (that is, left in a left-to-right schedule diagram). The Security should be taken care of from the very start of the project i.e. Design phase. Developers should design for security and make sure that Security is handled in every phase.

In software development, there are at least these four activities: design, develop, test, and release. In a traditional software development cycle, testing (including security testing), happens after development is complete. This typically means that a team discovers significant problems, including architectural flaws, that are expensive to fix as shown in the above diagram.

Teams can achieve better outcomes by making security a part of everyone's daily work instead of testing for security concerns at the end of the process. This means integrating security testing and controls into the daily work of development, QA, and operations. Ideally, much of this work can be automated and put into the deployment pipeline. By automating these activities, we can generate evidence on-demand to demonstrate that our controls are operating effectively; this information is useful to auditors, assessors, and anyone else working in the value stream.

How to implement improved security quality?

Shifting the security review process "left" or earlier in the software development lifecycle requires several changes from traditional information security methods, but is not a significant deviation from traditional software development methods on closer inspection.

Get InfoSec involved in software design

The InfoSec team should get involved in the design phase for all projects. When a project design begins, a security review can be added as a gating factor for releasing the design to the development stage. This review process might represent a fundamental change in the development process. This change might require developer training. It might also require you to increase the staff of the InfoSec team, and provide organizational support for the change. While including InfoSec might represent a change in your organization, including new stakeholders in design is not a new concept and should be embraced when considering the benefits.

Develop security-approved tools

Providing developers with preapproved libraries and tools that include input from the InfoSec team can help standardize developer code. Using standard code makes it easier for the InfoSec team to review the code. Standard code allows automated testing to check that developers are using pre-approved libraries. This can also help scale the input and influence from InfoSec because that team is typically understated compared to developers and testers.

Develop automated testing

Building security tests into the automated testing process means that code can be continuously tested at scale without requiring a manual review. Automated testing can identify common security vulnerabilities, and it can be applied uniformly as a part of a continuous integration pipeline or build process. Automated testing does require you to design and develop automated security tests, both initially and as an on-going effort as new security tests are identified. This is another opportunity to scale the input from the InfoSec team.

Common pitfalls

Some common pitfalls that prevent teams from shifting security left include the following:

    • Failing to collaborate with the InfoSec team. The biggest mistake is when teams fail to collaborate with their InfoSec teams. InfoSec is a vitally important function in an era where threats are ubiquitous and ongoing.

    • Understaffing InfoSec teams. InfoSec teams are often poorly staffed. James Wickett, Senior Security Engineer at Verica, cites a ratio of 1 InfoSec person per 10 infrastructure people per 100 developers in large companies.

    • Engaging too late with the InfoSec team. In many cases, the InfoSec gets involved only at the end of the software delivery lifecycle, when it is usually painful and expensive to make changes that are necessary to improve security.

    • Being unfamiliar with common security risks. Many developers are unaware of common security risks such as the OWASP Top 10 and how to prevent them.

Ways to improve security quality

You can improve software delivery performance and security quality by doing the following:

    • Conduct security reviews. Conduct a security review for all major features while ensuring that the security review process doesn't slow down development.

    • Build preapproved code. Have the InfoSec team build pre-approved, easy-to-consume libraries, packages, toolchains, and processes for developers and IT operations to use in their work.

    • Integrate security review into every phase. Integrate InfoSec into the daily work of the entire software delivery lifecycle. This includes having the InfoSec team provide input during the design of the application, attending software demos, and providing feedback during demos.

    • Test for security. Test security requirements as a part of the automated testing process including areas where preapproved code should be used.

    • Invite InfoSec to demos. If you include the InfoSec team in your application demos, they can spot security-related weaknesses early, which gives the team ample time to fix them.

Ways to measure security quality

Based on the stated ways to improve outlined above, you can measure security in the following ways.