Hey folks! Last week, I had the pleasure of sitting down with Dazz, a cloud remediation tool, to speak with their CEO on some fun topics. We spoke about vulnerability management, our top priorities, how to collaborate with our software engineering peers, and a few other great topics. I wanted to write a little bit about my thoughts. You can find the full length recording below
How Security Should Work with Software Development
Security engineering teams must be more collaborative and integrative with their software engineering peers. You must work with them almost as a single unit on large initiatives, rather than tossing tasks over the wall and asking for them to be completed. In place of bolting on security at the end of the software lifecycle, security should be inserted into processes that already exist.
To me, the most fundamental way to do this is to adopt a DevSecOps approach. If you Google "DevSecOps," you usually end up with nothing more than a laundry list of new tools to purchase and an incorrect understanding that if you have these tools, then you're doing DevSecOps correctly. This is not the case. DevSecOps is an approach to doing security and a mindset to have - not a toolset or a budget to spend. Simply put, this means intertwining software engineering and security processes to bring security earlier in your software lifecycle.
Security engineers should be able to write code. It doesn't have to be clean, but understanding how to build simple applications takes any engineer a long way. Not only does this let you build amazing things for your team, but it helps in understanding the developer's viewpoint when you're working with them directly. We take an "engineering-first" approach to nearly everything we do, allowing us to relate to our software engineering peers on a much higher level. When hiring, I look for candidates with some form of development experience. It is in no way a hard requirement; if you come across a great security engineer who doesn't know how to code, you should invest in them and their development.
How to Bring Security and Software Development Teams Closer
Make security as simple as possible. I am a huge advocate for applying security with GitOps. GitOps is the practice of running operations through standard Git workflows. For example, approving an IAM request through reviewing a pull request and then having the changes automatically applied through IaC after merge. I put a lot of work into integrating as much of our security as possible into the software engineering team's existing workflows. A great example of this is leveraging pre-existing CI/CD pipelines. This gives developers continuous feedback on their work without ever having to manually ask for a security review or scan. Any security findings are being presented to them immediately when they commit code and open a pull request, not from a bunch of security tools bolted onto the end of their software lifecycle when a release candidate is cut. You can even take this a step further and integrate your security tooling into your developer's IDEs, giving them continuous feedback as code is being written. These are great examples of how you can adopt a DevSecOps approach.
Process transparency is another great way to build relationships with external teams. Socializing your processes, soliciting feedback, and improving them based on other's comments is extremely valuable. This ensures that you don't build processes in a bubble, which will only work for your team and no others who are involved.
Point Products vs Platform
In the webinar, I briefly discussed my opinion on going with a point product vs a platform product. Meaning, my thoughts on going with a smaller vendor that fulfills a single function for your team, or going with a much larger vendor that sells you a "platform" that fulfills many functions for your team. There are quite a few pros and cons here, but I generally go for best-of-breed products.
For starters, I almost always find that a company focused on one thing does that single thing much better than a company that happens to have that capability within their platform. It also greatly depends on your maturity. If it's your first time deploying a new tool type or function, you could be successful with a platform product. If you've been running a function for years, and you know exactly what your gaps are and where you need to improve, you've likely outgrown a platform tool and need a point product.
If you like being hands-on with your vendors, best-of-breed shops tend to be much smaller and allow for this sort of relationship. This means getting early access to features, more candor, and greater influence on product development.
Of course, price also plays a role. Generally speaking, you can save some money going with a platform product. Perhaps you can't afford to buy and operate best-of-breed products for everything you do. If so, find out where you need a platform and where you need a point product - the best of both worlds.
Wrapup
Lastly, Dazz is a great product. Obviously, I am biased here, but it's the first time we've seen a vuln-management-esque tool that was so well aligned with our toolset. No more building clunky connectors, syncs that only work half the time, and manual finding aggregation and analysis. To me, one of the most valuable features is their ability to help with root cause analysis. You don't want to be stuck in the loop of patching symptoms of a much larger problem, and Dazz helps us go directly to the root. For example, let's say your CSPM is reporting an issue from a deployed container on the edge. Dazz looks at that issue, correlates it back to a container image sitting in your registry, and ties that container back to a Dockerfile in your source code. Now, you can go update a base image or update some of the image layers, and you've remediated a whole chain of issues with one update. We've been able to do some incredible things with Dazz, and are planning to use it to drive almost all of our vulnerability remediation through it.