Born-left allows developers to fully own the security process. Here’s what you need to know about the emerging trend.
You’ve probably heard of shift-left security: the movement to bring security closer to the start of the development lifecycle. The shift-left approach was born out of the need to avoid having to add in security activities and controls after the fact – which results in delivery delays, significant added costs, and a lot of friction to the development process.
The shift-left model is now well-regarded as best practice in the industry. But it is far from a perfect solution, and a further shift is still needed.
In this article, I’ll be laying out the limitations of shift-left security before introducing an alternative, more effective solution: born-left security.
When does shift-left security go wrong?
While all the concepts and best practices to do with cloud application security sound better when you prefix them with ‘shift-left’, in practice, it can be extremely tough to implement.
Within almost any organization, there is probably a lack of specialized knowledge for building a shifted-left product-security program that won’t frustrate the engineering team.
Not only this, with a wide range (being very conservative) of controls and interfaces, plus a need for overlaying product security processes where human interaction is required, it’ll dawn on the organization that complete automation simply isn’t possible.
When asked about the challenges of implementing shift-left security, various teams and folks in different roles will invariably say a lack of leadership support, as well as lack of engagement from developers. Without buy-in from both these sides, changing practices is doomed to failure. When you dig in further, you will learn that this lack of support is natural as today’s shift-left tools and practices are simply not enough.
Developers are required to chase velocity, keep things agile, and with all respect to the level of automation of shift-left controls, they are creating endless noise, which easily leads to alert fatigue.
Not only this, you still need extensive product security knowledge to implement the right tools that will also be aligned with a solid security plan. Where would you start?
All too often, shift-left tools are mainly security tools that were modified for developer use – for instance a native experience in Github – but they are interfering with the main mission in maintaining dev velocity and agility.
Think about today’s startups. We are talking about ultra lean organizations, where almost every aspect of the product is owned by the engineering organization. But even with the plethora of shift-left security controls, this is just too complex to manage properly. There’s no organized strategy, or a solid plan for managing product security challenges. Nobody knows which tools should be implemented, how to properly implement them, what calibrations to make, which alerts to ignore, which others to insist on fixing, how to ensure that a minimal viable security standard is met, and… you get the idea.
So, product security is being compromised, and a bunch of developers are becoming frustrated along the way. As a result, they’re not just developing software, they’re developing resentment.
What is born-left security?
While shift-left security continues to come of age, I predict that we will also see the rise of born-left security. When I talk about born-left solutions, I refer to solutions that were built for developers as landowners, not just users. Such tools have the KPIs of supporting velocity while managing security, and prioritizing the developer experience on top of everything else.
When developers build solutions for their own kind, they do things differently. After all, nobody understands the pains better than they do…
To be practical, if you want developers to love a security solution, you need to solve these challenges:
- It has to start with (and therefore include) a solid product-security plan that is tailored to their product (or industry, or the marketplace they are adding their apps to) and that is accessible for them.
- The plan should be standardized, and not something that developers are required to create – they are software engineers, not security experts. They need to be able to get it off the shelf. In practice, think of a Minimal Viable Security plan like the one described in an article in OpenView.
- Such a solution should include full automation of the plan execution, including orchestrating the needed controls – end to end.
- And last but not least, such a solution should exist within the developers’ native environment and workflows, to create an experience which is familiar with a low barrier to entry.
Of course more advanced features can include multiple capabilities such as noise reduction, wide product security aspects, AI capabilities on top, knowledge shared between developers, and more.
Born-left solutions will not run over shift-left, as they will have to leverage shift-left controls, but they are the only way that dev organizations can truly own product security without compromising on their underlying mission.
To summarize, born-left security tools can be managed by DevOps, DevSecOps, or by a security developer, but they are different in nature from shift-left tools. This is because they revolve and originate from the product security plan and are fully aligned to the main KPIs of the dev organization – seeing these as the only stakeholders that they are serving.
This will eliminate the anxiety and alert fatigue, remove objections and constraints, and will not add extra overheads for developers, but rather the opposite – eliminating time spent returning to code to fix security issues that arise too late.
A special bonus: they will make compliance processes much easier to manage …
How to foster born-left security in your organization
In order for engineering leaders to foster a born-left security mindset in their organizations, the critical piece starts with transferring ownership of product security to developers, by making security more accessible to them in the following ways:
- Having security be configured, managed and implemented as code.
- It should be fully automated and continuous, like other continuous processes that have moved to the ownership of developers like CI or CD.
- Shift the mindset from endless logs and findings to concise and actionable recommendations.
- When possible, unify detection and remediation into a single platform.
All of these together make security more dev-native, and enable security to be born left and fostered from as early as the first line of code.
Reflections
Born-left security is still in its budding infancy, and many organizations are still grappling with the challenges in moving to a shifted left security process. This means it’s an exciting time for security, and there are sparks and upstarts trying new things and seeing great results. We all know that things move fast in tech, and born-left automated product-security for engineering teams can help alleviate the pain.
