If you’re interested in receiving interviews with thought leaders and a digest of exciting ideas from the world of DevOps straight to your inbox, subscribe to our 0800-DEVOPS newsletter!
###
Tanya Janca, also known as SheHacksPurple, is a super kind person bringing a security focus to DevOps movement. After working for the government and Microsoft, Tanya is now focused on consulting and education. She even runs an OWASP chapter! I talked with Tanya about security in the cloud and how does one go about making teams more sensible to security issues.
Take a look at our conversation, I found so many good ideas here.
Here’s how Tanya sees addressing security concerns in DevOps environments these days
Tanya: That could be a book! I would say that app sec people need to adjust the way they’re doing security.
In waterfall security would be a gate, you would need to jump through these hoops and then you could go to the next thing. But that doesn’t work very well in DevOps, because they want everything to be automated, they want everything to go really fast.
There is a bunch of strategies. One of them would be breaking your security activities into sprint-sized bites. If you’re going to do code review, only review code from that sprint or only do a certain feature set or certain amount or do the APIs…so it fits into a sprint and you can get them the results to fix in the following sprint and make sure there is time in the following sprint allocated to them to fix those things.
Another thing could be adding some security testing to the pipeline. For instance, scanning to make sure no one is checking-in a secret, for instance a password with a username combo or a hash or something. If you can just do a check for that, that’s very very quick, especially if you’re just checking the ‘delta’, just parts of the code that have changed, that are being checked-in. People are checking-in things 10 times a day, they don’t want to wait 25 minutes every time. So if you’re just checking very very quick things and things that are very important, that could be something developer would be OK with.
A lot of places I’ve seen they try to put a SAS product in and then the SAS product is just trying to scan the whole thing and it’s like ‘Well, OK, see you tomorrow when it’s done running!’.
And we can’t really do that now!
Another strategy that I’ve done before is creating another pipeline.
Most pipelines that we talked about, they do all these tests and they promote it from a dev server where some tests are run and then to another place and another place and another place and then it goes to prod ideally and it goes out into the world and people get to use that software.
But you can create more pipelines. If you’re doing infrastructure as code you would have another pipeline that will publish your infrastructure and then if you’re doing APIs you would have another one that publishes your API…so why not duplicate one of those and then run your in-depth security testing but don’t have it go to prod, don’t have it go to all the environments, just have it to go to one place that’s allocated for security testing and then run your 18-hour SAS and do that maybe once a week. Have it kick-off and it tests you know this API or it tests this infrastructure is code or, of course, ideally your application.
Then you’re not blocking the prod release and then perhaps just running your SAS product only on the ‘delta’ of that one tiny piece of code or train your software developers they’re approving pull requests to do secure code review and tell them they need to do that on each commit and then once a week we’re running the full SAS and then we are going to evaluate the results which will take a human another day or two maybe. You can’t just send SAS results to a developer like that, that’s developer cruelty!
