Security is a dilemma for many leaders. On the one hand, it is largely recognized as an essential feature. On the other hand, it does not drive business. Of course, as we mature, security can become a business enabler. But the roadmap is unclear. With the rise of Agile practices, DevOps and the cloud, development timeframes have been considerably compressed, but application security (AppSec) remains essentially the same.
AppSec: From Requirements to Expectations
Scaling application security is a company-wide project that requires thorough thinking before any decision is made. First, it is necessary to talk to product and engineering teams to understand the current global state of AppSec maturity.
The objective is to be sure to have a comprehensive understanding of how your products are made (the processes, tools, components and stacks involved). Mapping development tools and practices will require time to have the best visibility possible.
They should include product development practices and the perceived risk awareness/appetite from managers. One of your objectives should be to nudge them so they take into account security in every product-related decision they make and to begin thinking like adversaries would.
You should be able to derive security requirements from the different perceptual risks you are going to encounter. Your job is to consolidate these into a common set of security requirements for all applications, setting goals to align the different teams collaborating to build your product(s).
Communicating transparently with all relevant stakeholders (CISO, technical security, product owner and development leads) about goals and expectations is also essential to create a common ground for improvement. It will be absolutely necessary to ensure alignment throughout the implementation stage, too.
Open and Accessible Guardrails
Guardrails are the cornerstone of security requirements. Their nature and implementation should be unique to the needs of your organization and can be potentially very different from one company to the other. If you’re starting from scratch, look no further than the OWASP Top10). What is most important, however, is that these guardrails are open and accessible to anyone that needs them. A good example of this would be to centralize a common, security-approved library of open source components that can be pulled from by any team.
Keep users’ accessibility and useability as a priority. Designing an AppSec program at scale requires asking, “How can we build confidence and visibility with trusted tools in our ecosystem?” For instance, control gates should never be implemented without considering a ‘break glass’ option (“What happens if the control is blocking in an emergency situation?”).
State-of-the-art security requires having off-the-shelf security solutions chosen by the developers, approved by security and maintained by operations.
This will be a big leap forward and go a long way toward preventing vulnerabilities from creeping into source code. It will bring security to the masses at a very low cost (and low friction). But to truly scale application security, it would be silly not to use the software engineer’s best ally: The continuous integration pipeline.
Embed Controls in the CI/CD Pipeline
AppSec testing across all development pipelines happens in the implementation step. If your organization has multiple development teams, it is very likely that different CI/CD pipeline configurations exist in parallel. They may use different tools or simply define different steps in the build process. This is not a problem, per se, but to scale application security, centralization and harmonization are needed.
As illustrated in the following example CI/CD pipeline, you can have a lot of security control steps: Secrets detection, SAST, artifact signing, access controls and container or infrastructure-as-code scanning (not shown in the example).
(taken from the DevSecOps whitepaper)
The idea is that you can progressively activate more and more control steps, fine-tune the existing ones and scale your AppSec infrastructure both horizontally and vertically on one condition: You need to centralize metrics and controls in a standalone platform able to handle the load corresponding to your organization’s size.
Security processes can only be automated when you have metrics and proper visibility across your development targets, otherwise it is just more burden on the AppSec team’s shoulders.
In turn, metrics and visibility help drive change and provide the spark to ignite a cultural change within your organization. Security ownership shifts to every engineer involved in the delivery process, and each one is able to leverage their own deep (yet partial) knowledge of the system to support the effort.
This unlocks a world of possibilities: Most security flaws can be treated like regular tickets, rule sets can be optimized for each pipeline based on criticality, capabilities or regulatory compliance, and progress can be tracked (saved time, avoided vulnerabilities, etc.). In simpler terms, security can finally move at the DevOps speed.
Conclusion
Security can’t scale if it’s siloed, and slowing down the development process is no longer an option in a world led by DevOps innovation. The design and implementation of security controls are bound to evolve. In this article, we’ve depicted a high-level overview of the steps to scale AppSec.
This starts with establishing a set of security requirements that involve all the departments, in particular, product-related ones. From there it becomes possible to design guardrails to make security truly accessible with a mix of hard and soft gates. By carefully selecting automated detection and remediation that provide visibility and control, you will be laying a solid foundation for a real model of shared responsibility for security.