Spending Developers on Security - Part 2
July 11, 2018

Hillel Solow
Protego

How much are organizations investing in the shift to cloud native, how much is it getting them? ...

Start with Spending Developers on Security - Part 1

What's it Going to Cost Me?

Let's boil that into time spent. Let's assume a 50 person development organization, managing 500 functions, where each developer deploys a new version 3 times a week. Remember, in serverless, people tend to roll out changes more frequently, but then again the changes are often small (which is why the two-minute strategy can work in the first place).

So you're rolling out 3 ⨉ 50 = 150 versions a week across your teams, or 150 ⨉ 52 = 7,800 versions per year. From my experience, this is a low estimate. We have customers with considerably higher rates.

Let's assume that we measure how much time a developer or devop engineer spends on security per deploy, how frequently the permissions are missing which causes an exception during testing or production, and how much time is spent. Of course, these are just based on a small survey and you can play with numbers as you see fit.


As you can see, exceptions are pretty costly, as they are out of context. Also, as you read the impact of this, bear in mind that the level of security attained (as in, how well the security posture prevents future attacks and damages) varies drastically between the three strategies. Also, I've tried to estimate the yearly average rates. Exception rates are much higher for new functions, and drop much lower for mature functions, so this is just a simplification.

Here's how that adds up per year:


If we translate that into dollars, assuming a cost of $150k per engineer ($120k salary + $30k additional costs), you are spending:


Can I Improve on That?

You can, of course, try to make all your developers fundamentalists when it comes to security. There is no doubt that a little security awareness goes a long way. Having said that, it's a pretty expensive way to get the security you need.

Let's compare that to using tools to help you close the gaps. The idea is that if you have the right tools in place, within your deployment and monitoring workflows, then you catch things as early as possible, give developers detailed guidance on when, where and what to focus on, and keep security overhead to a minimum. You can achieve or even exceed the levels of the Fundamentalists, while spending less time than the Minimalists.

Let's add in the security tool strategy to the mix:


The main trick is to spend under a minute on average per deploy (mostly that's adding permissions you know you need, and handling build-time errors that come from wrong permissions). A side benefit is that the number of exceptions also drops significantly, since the security tools usually catch missing permissions as well, and you can fix that while the files are still open in your IDE.

How does this add up yearly?


So as you can see, while freeing up significant developer time, you can also improve your security, if you have the right tools in place.

Hillel Solow is CTO and Co-Founder of Protego

The Latest

November 15, 2018

Serverless infrastructure environments are set to become the dominant paradigm for enterprise technology deployments, according to a new report — Why the Fuss About Serverless? — released by Leading Edge Forum ...

November 14, 2018

What to automate? Which parts of the delivery process are good candidates? Which applications will benefit from automation? At first, those sound like silly questions. Automate all your repetitive processes. If you think that you'll do the same thing manually more than once, automate it. Why would you waste your creative potential and knowledge by doing things that are much better done by scripts? Yet, an average company does not adhere to that logic. Why is that? ...

November 13, 2018

I'd love to see more security automation deeply integrated into the development process. Everybody knows since the 1990s that security as an afterthought just doesn't work, yet we keep doing it. The reason, I think, is because it's very hard to automate security ...

November 09, 2018

DEVOPSdigest asked experts from across the IT industry for their opinions on what steps in the SDLC should be automated. Part 5, the final installment, covers deployment and production ...

November 08, 2018

DEVOPSdigest asked experts from across the IT industry for their opinions on what steps in the SDLC should be automated. Part 4 is all about security ...

November 07, 2018

DEVOPSdigest asked experts from across the IT industry for their opinions on what steps in the SDLC should be automated. Part 3 covers the development environment and the infrastructure ...

November 06, 2018

DEVOPSdigest asked experts from across the IT industry for their opinions on what steps in the SDLC should be automated. Part 2 covers the coding process ...

November 05, 2018

Everyone talks about automating the software development lifecycle (SDLC) but the first question should be: What should you automate? With this question in mind, DEVOPSdigest asked experts from across the IT industry for their opinions on what steps in the SDLC should be automated. Part 1 starts with by-far the most popular recommendation: Testing ...

October 31, 2018

Halloween is a time for all things spooky, but not when it comes to your mobile app experience. A poor experience can not only scare off your customers but keep them away for good ...

October 30, 2018

As organizations have embraced open source, they have become polyglot — using multiple programming languages and technology stacks to accomplish software and hardware related tasks. Enterprises are caught between the benefits provided by a polyglot environment and the complexities and challenges these environments bring. Ultimately, if the situation remains unchecked, polyglot will kill your enterprise ...

Share this