Editor’s note: This is Part Two of a four part series, talking with Bryan Batty, Director of Product and Infrastructure Security at Bloomberg Industry Group. In Part One, we talked about the use of open source components and how to manage their usage through Software Composition Analysis (SCA) tools. In this section, Bryan discusses his ideas around making security an essential part of the software supply chain.
"If you had nothing else, at least know that you can version your software, and that two different people working on it at the same time aren’t going to step on each other's toes." -- Bryan Batty
Building a Secure Pipeline
Mark Miller:
If somebody is trying to wrap their head around the idea of a DevOps pipeline and putting security in as DevSecOps, where do you start?
Bryan Batty:
There are many different answers to that question. It depends on how big your organization is, how mature your pipeline is already. If you don't have a pipeline, build a pipeline.
Mark Miller:
Define pipeline, what's a pipeline?
Bryan Batty:
That would start with the source control system. If you had nothing else, at least know that you can version your software, and that two different people working on it at the same time aren’t going to step on each other's toes. Even with modern pipelines, that does happen a little bit. Like GitHub, if you forget to pull before you push. There are issues with merging other people's changes into your code.
Start out with a good source control system and also continuous integration. Basically, a good delivery pipeline, when you're building software, includes quality gates along the way. Those quality gates are usually for testing, and you want to test to make sure the software is doing what it's supposed to do and nothing else.
Developers and development teams are already on board with that. Yes, they want to test their software before they put it into production. Security is the same thing. We want to get security integrated as far left as possible in the pipeline.
You want to get feedback back to the developers as quickly as possible without taking too much of their time. Some of the very fast items, like SCA, are faster than static and dynamic analysis or testing by a running piece of software. SCA can be run early and throughout the pipeline.
Static analysis can be very slow sometimes, depending on how big the source code base is. But you want the faster tests done earlier. Then manual penetration testing, which should be done from time to time. You might not be able to do it with every single sprint. Have an application security specialist sitting in with the developers on their sprints and try to pen test the deltas.
Instead of doing comprehensive penetration testing of the entire application, just pen test what has changed during that sprint. I’m experimenting with it right now. I don't know if it's going to be sustainable, but it's interesting when people are excited to see it work.
A full blown comprehensive manual penetration test might only be done once a year. You certainly wouldn't want to do that very far left in the pipeline. There are things you might have been able to catch and fix, and get back to the developer, before taking a two week engagement to do something like that.
Changing Security Models
Mark Miller:
Does the security model change for you when people are using containers versus a regular pipeline?
Bryan Batty:
I don't think the model changes, but certain tasks definitely change. Normally, when we're talking about application security, we're talking about the DevSec portion. When you're looking at containers, you're looking at the Ops part of DevSecOps. Ops doesn't usually come into play when we're just talking about application security professionals.
What are the developers doing? What's in the pipeline? But now developers are deploying infrastructure and they're deploying containers, which has all the resources needed to run an application. A container isn't an Amazon Machine Image, but it's something like that and people pull those from different places. They pull them from the internet, so we need to make sure that the containers they pull don't have any security vulnerabilities.
Software Bill of Materials (SBOM)
Mark Miller:
One of the things that the government is considering is mandating that there be a software bill of materials attached to any application sold. What’s your say on that? Yay? Nay? As a practitioner, would you want a software bill of materials requirement?
Bryan Batty:
I think that would be nice. I bristle whenever I hear the government wants to do this to our industry, or to any industry, but especially my industry. I go back to the privacy laws like GDPR and CCPA. Generally speaking, I don't like that, but practically speaking, seeing what privacy issues that the tech giants have really exploited… they just trample all over our rights completely.
Something has to be done. So there are times where I say, "Okay, my libertarian sensibilities can be a little bit flexible." In this case the software bill of materials, being able to have that and know what is inside if I'm purchasing a piece of software, I’m okay with that.
In my case, at work, we also sell software. We have a vendor security questionnaire that we give out to all of our vendors and anybody buying our software does as well. The existence of a software bill of materials is not one of the questions, but I don't think it would be a bad idea to include that.
Now should the government do it or should there be a third party, like PCI compliance? In my view there should be somebody like that. Somebody is the authority and everybody else has agreed that yes, this body is the authority and they will vet third party software or building materials.
This is Part Two of our discussion with Bryan Batty. Catch up by reading Part One, where he describes using Software Composition Analysis (SCA) tools. In Part Three he explains his views on experimentation and measuring success. Finally, in Part Four, he shares why he selected the Sonatype Platform.
