ShiftLeft released a new version of NextGen Static Analysis (NG SAST), including new workflows, purpose-built for developers that significantly improve security, while enhancing productivity.
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.