Security is a dilemma for many leaders. On the one hand, it is widely recognized as an essential characteristic. On the other hand, it does not stimulate 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 timelines have been dramatically compressed, but application security (AppSec) remains essentially the same.

DevSecOps emerged as an answer to this dilemma. Its promise lies in inserting security principles, practices, and tools into the DevOps workflow, thereby reducing risk without compromising deliverability.

So, Why isn’t DevSecOps the norm already?

Recent research from GitGuardian, DevSecOps: protecting the modern software factory revealed that culture is the sticking point and a major barrier to greater adoption of DevSecOps. Only by activating new abilities in the Dev, Sec, and Ops teams can the culture be changed.

This article will help provide a high-level overview of the prerequisites needed to harden application security across departments and enable these features.

AppSec: from requirements to expectations

Scaling application security is an enterprise-wide project that requires careful thought before any decision is made. First, talking to the product and engineering teams is necessary to understand the current state of AppSec’s global maturity.

The goal is to be sure you have a complete understanding of how your products are made (the processes, tools, components and batteries involved). Mapping development tools and practices will take time to gain the best possible visibility.

They should include product development practices and managers’ risk perception/appetite. One of your goals should be to inspire them to factor safety into every product decision they make and to start thinking like opponents would.

You should be able to deduce the security requirements from the different perceptual risks you are going to encounter. Your job is to consolidate them into a common set of security requirements for all applications, setting goals to align the different teams collaborating to create your product(s).

Communicating transparently with all relevant stakeholders (CISO, technical security, product owner, and development leads) about goals and expectations is also key to creating a common environment. ground to improve. It will also be absolutely necessary to ensure alignment throughout the implementation phase.

Open and accessible railings

Guardrails are the cornerstone of security requirements. Their nature and implementation should be unique to your organization’s needs and can potentially be very different from company to company. If you’re starting from scratch, look no further than the Top10 OWASP). Most important, however, is that these guardrails are open and accessible to anyone who needs them.. A good example would be to centralize a common, secure library of open source components that can be pulled by any team.

Make accessibility and user friendliness a priority. Designing a large-scale AppSec program requires asking, “How can we build trust and visibility with trusted tools in our ecosystem?” For example, control doors should never be set up without considering a “glass break” option (“What happens if the control jams in an emergency situation?”).

State-of-the-art security requires off-the-shelf security solutions chosen by developers, approved by security, and maintained by operations.

This will be a big step forward and will go a long way in preventing vulnerabilities from creeping into the source code. It will bring security to the masses at very low cost (and low friction). But to truly scale application security, it would be silly not to use a software engineer’s best ally: the continuous integration pipeline.

Integrate controls into the CI/CD pipeline

AppSec testing on all development pipelines takes place during the implementation stage. If your organization has multiple development teams, it is very likely that different CI/CD pipeline configurations exist in parallel. They can use different tools or just define different stages in the building process. This is not a problem in itself, but to evolve application security, centralization and harmonization are necessary.

As shown in the following example CI/CD pipeline, you can have a ground security control steps: secret detection, SAST, artifact signing, access controls, and container or infrastructure-as-code analysis (not shown in the example).

(taken from DevSecOps White Paper)

The idea is that you can gradually enable more and more control stages, refine existing ones, and scale your AppSec infrastructure both horizontally and vertically on one condition: OYou need to centralize metrics and controls in a standalone platform able to manage the load corresponding to the size of your organization.

Security processes can only be automated when you have proper metrics and visibility into your development goals, otherwise it’s just an additional burden on the shoulders of the AppSec team.

In turn, metrics and visibility help drive change and provide the spark to trigger cultural change within your organization. Security ownership passes to each engineer involved in the delivery process, and each is able to leverage their own deep (but partial) knowledge of the system to support the effort.

This opens up a world of possibilities: most security breaches can be handled like regular tickets, rule sets can be optimized for each pipeline based on criticality, capacity, or regulatory compliance, and progress can be monitored (time saved, vulnerabilities avoided, etc.). In simpler terms, security can finally evolve at the speed of DevOps.

Conclusion

Security cannot scale if it is siled, and slowing down the development process is no longer an option in a world driven by DevOps innovation. The design and implementation of security controls is bound to evolve. In this article, we’ve outlined a high-level overview of AppSec scaling steps.

It starts with establishing a set of security requirements that involve all departments, especially those related to products. From there, it becomes possible to design guardrails to make safety truly accessible with a mix of rigid and soft barriers. By carefully selecting automated detection and remediation that provides visibility and control, you’ll lay a solid foundation for a true shared responsibility model for security.

Finally, the integration of verifications into the CI/CD system can be deployed in phases to gradually scale your security operations. With automated feedback in place, you can begin to gradually adjust your policies. A centralized platform creates a common interface to facilitate exchange between application security and development teams while enforcing processes. This is a huge opportunity to automate and propagate best practices across teams.

Developers are empowered to grow faster with more ownership.

When security is reimagined as a partnership between software building stakeholders, a flywheel effect can occur: reduced friction leads to better communication and visibility, more automation of best practices, and reduced workload while improving security with fewer defects.

This is how application security can finally evolve through continuous improvement.