All application components and map your CI/CD from cloud to code to build an inventory & SBOM
January 11 2022 | 4 min read
Executive, Technical | January 11 2022 | 4 min read
I was speaking with an experienced Application Security Architect recently when he made a stunning statement: he spends the majority of his time in Jira reviewing user stories that may introduce risk into the company’s applications. After many more conversations, I’ve come to realize that this is not unique – the same sentiment resonates with many practitioners in the AppSec industry. In many ways, this is a great example of the “shift left” philosophy of identifying potential risks before they reach production. At the same time, it highlights how far we still have to go before application security is deterministic, automated, consistent, and efficient
The rapid growth in recent years in the speed of development is making “Security at the Design” ever more critical. Business priorities are changing rapidly and new user stories, feature requests, and bug fix requirements are changing on a daily basis. Every new change request has the potential to introduce risk into the system. At the same time, Agile development moves fast and Engineers often begin development without a security review because the AppSec team is outnumbered (by 159 to 1, according to BSIMM)!
Waiting for implementation and discovering issues in testing (or even production!) is no longer an option. The later an issue is discovered, the more rework is required, leading to higher costs and slower delivery. This is why security risks now need to be identified at the design.
Unfortunately, identifying the user stories that require AppSec attention is also increasingly difficult and security professionals are struggling to keep up with the sheer volume of change requests.
The AppSec engineer is responsible for securing the output of several hundred developers across multiple teams; waiting for vulnerabilities and other security weaknesses to reach production is simply not a viable strategy. Preventing security issues before they are implemented is the most efficient (and some would even say the only) way their organization can effectively understand and remediate risk.
When Application Security engineers look through user stories, they are looking for a number of things, including:
The answer to any of these questions can ignite a conversation between Security and Development teams or trigger a defined security process, such as a Threat Model or Security Code Review. As an Application Security professional, there are a few keys to making security at the user story successful:
All risk is contextual and Apiiro takes this approach to securing applications at the feature request, commit, PR and CI/CD time, before deploying to production. In agile, the code is the design. There is often no formal process for documenting changes that must pass a detailed security review by Application Security professionals who are overworked and outnumbered.
We have often spoken about providing risk-based Application Security from design to code to cloud, but a “shift left” approach is actually the opposite. Configuration data in the cloud can be used to better understand risk at the coding and design stages.
The Apiiro platform analyzes text, code and configurations across the entire SDLC in order to build a risk graph that provides a comprehensive risk assessment at each stage of the SDLC.
With a comprehensive understanding of risk, creating an effective Application Security program that starts at the user story is finally possible.