Once upon a time you needed to hand-tune and architect infrastructure to performantly serve static assets at scale. However, now, getting started with a CDN or storage buckets is as easy as can be. Many services completely abstract away such concerns altogether.
Once upon a time you needed to know the details around a distributed consensus algorithms to build out a scalable and fault tolerant database system. However, now, all the major cloud providers offer database services that any startup can utilize at the click of a console button.
Burdening those who wanted these benefits with knowing how to do it themselves or care more about having that expertise in-house was the wrong way to go about things. Making them easy to use and attain was the correct way to increase adoption.
Every piece cloud infrastructure has security related surface area
Devops tools benefit from the stratification that occurs in the toolchain — each layer is a prime candidate for simplification and ease of use. You plug the tool into your workflow and it just works. Fast moving teams have high expectations of their tools and are at a competitive advantage if their engineering teams don’t need to reinvent the wheel.
In 2021 these are minimums that effective engineering teams have come to expect. Shifts in abstraction continue to make product development easier and faster.
Security, on the other hand, hasn’t made the same strides. Further exacerbating the situation for startups is that the hurdle of security squarely falls in the bucket of tech-debt. It is only an impediment — with zero product benefit for end-users (of course, unless, the product itself is security focused).
At some inflection point stakeholders begin to realize that it’s time to start paying down security-related tech-debt.
The industry expects developers to broadly and deeply educate themselves about security and all the technical details that come with it. Furthermore, it doesn’t fit neatly in the devops paradigm.
Do dependency confusion attacks fit within the build system or is that a deployment concern?
Is the security of an expiring domain name the responsibility of an engineer or the person managing the credit card that’s expired?
Whose responsibility is it if someone has been temporarily added as an external contributor to a git repo?
What happens if an SRE needed to make an emergency change outside of IaC directly to a cloud console in response to an outage? Where is the drift tracked?
Asking teams to shift left is an antiquated way to reason about security in a modern cloud-native context. The problem is not that developers are isolated from security concerns.
Of course all teams and stakeholders want to be doing the right thing. If presented with a choice, any reasonable engineer would pick the more secure option. However, they aren’t presented with an easy to digest and actionable route. After a startup founder has made a slew of changes, all they want to know is what’s wrong and change it to the sensibly secure option. Some complicated severity and priority matrix with a link to a CVE isn’t helpful. They need to be presented with easy and actionable guidance. Expecting them to act upon esoteric advice and becoming experts in all things security is a recipe for them to continue to ignore it and accumulate security tech debt.
Turning the gain up on getting people to care more about security is the wrong approach. It needs to be made easier across the board. Expecting users to grant all permissions and then gradually ratchet them down has been shown time and again to be insufficient. Services need to provide engineers an easy path from a default state of no permissions up to the required permissions for a feature to work. Time spent blazing this path is far more valuable than educating developers to care more about security; they already do.
