Be a maker for DevSecOps

- I want to discuss something that's going to be really important for security over the next decade. Security wins by being a maker. Makers are inverse to breakers or critics of a system. Makers build, they create. Makers add value. Now that isn't to say breakers, which you can easily classify as red teams or pen testing. It's not that they're not valuable. You know, they are. But instead of just focusing on how to break a system, security becomes part of the software creation process. You know, one of my favorite sayings about our industry is that software is a team sport. I've had the opportunity to work in a few high-performing software delivery organizations, and one trait that they all share is that they follow this motto. We build and create software together. Everyone in the organization is responsible for the quality of software that is delivered. This includes security. Now security is not an other. Security is not an outsider looking in and just pointing out mistakes. No, security is involved in the creation of the software and involved in the software pipeline. You may not like this as a security professional because this often means that security needs to write code. Now before you object to that, I want to ask you this. Doesn't InfoSec have a similar saying? You know, we do, and it's that security is everyone's responsibility. This comes from a very similar spirit wherein security can only function if everyone in the organization is taking part. This doesn't mean that someone in HR has to be able to identify cross-site scripting. But it does mean that each person plays a part in the organization's overall security posture. What I am suggesting here is that security is best served by being able to write code. Take part in the building and add value to the software in the systems of our organization. We don't do this by leading the software development process, but we do it by adopting the tools and the languages of makers. In my experience, this has three main benefits. And I want to start with the most unexpected one, empathy building. We build empathy by gaining firsthand experience of what dev and ops teams have to do when they release features or they write new code. We gain an understanding of their requirements and what they face on a day-to-day basis. This has given me a lot of perspective on how to make security less of a roadblock and more of a natural facet of the system. We move testing and security tooling inside the pipeline and solve problems together as makers. The second benefit of bein' a maker is a faster incident response. Now by adding security testing practices and tools inside the pipeline, everyone's more aware of what security defenses are in place. And how to respond when things go wrong. One kind of trivial example is the web application firewall, or the WAF. Often in many organizations, the development team has no access or insight into what the WAF is doing. The developers see the side effects and the false positives in the form of errors, but security often doesn't give them actual access to the system. In a DevSecOps world, security makers provide an API for the WAF, and developers can in operations, they can integrate that into their ChatOps stack, or into their observability tools. So instead of guessing what state the system is in, the teams can know if they're under attack. They can often triangulate a response much faster. The third and last benefit is security as quality. In the 2019 DevSecOps Community Survey, one out of four respondents said that they were doing their DevSecOps journey because they believed it would result in higher quality software. Quality is a term that is used to express value for the business. You know, if you get a bunch of executives together, there will be some interest in building more secure software. That's pretty natural. But if you approach security as a function of building higher quality software, then they're going to lean in and they're going to want to hear more. Let's sum it up. By being a maker, you get insight into the lives of the people who are responsible for the system. You understand what they face, you build empathy. Then you enable everyone to respond faster to incidents when they happen. And lastly, you ultimately are creating higher quality software, by getting to the heart of the organization and what they really value. If you choose to follow this tip, you will find yourself working with development teams to implement security as a maker. It's different, it takes a change in mindset. But the benefits to security and your career are there for the taking.