Very simply it means always start with security.
The term “shift left” is used to describe taking a process that is typically performed later in a process and moving it earlier in the lifecycle. Much like in car manufacturing, shifting left would be taking a function and moving it closer to the design process rather than at the end when the car is fully assembled.
The cost Issues identified earlier in the design process are much easier and less expensive to fix than problems found after delivery. It could cost at least 6x more to fix a bug found during implementation than to fix one during the design phase, and 15x more during the testing phase.(SOURCE: IBM Systems Sciences Institute)
Security is no different. It is important to bring automation, visibility and transparency into ALL the domains of security as early into the development process as possible. Going beyond the just the technology and process by also focusing on the people. By helping the people (e.g. developers, operators, SRE) understand security requirements, risks and controls there can be a partnership towards the same outcomes. Developers should not have to ask risk and security teams "why are you making me do that", it should be clear to everyone what the requirements are and importantly why they are important.
Shift Security Left is not a term or a trend, it is our mission.
Our central focus is to deliver solutions that break down each security domain to meaningfully reduce risk as early in the process as possible through automation, transparency and education. A result of Shifting Security Left is making tedious, complex and mundane governance, risk and compliance easy right out of the box. This allows enterprises to move like a start-up and a start-up to have the capabilities of an enterprise.
To be truly be successful in shifting security left is to leverage continuous validation with a holistic end-to-end solution for delivering code and infrastructure.
Which is the reason we developed Infrapipe. It is the central point of the platform to provide the capabilities needed to shift security left and achieve compliance at DevOps speed.
Start-ups vs. Enterprise
Having spent years in large, highly regulated, enterprises where managing risk, governance and compliance is a very focused outcome. There are many resources that are dedicated to a defined cyber security program with teams focusing on each domain. We have also successfully launched regulated start-ups where agility and delivery are the primary outcomes, but do not have the resources to have dedicated security personnel. Each case, while vastly different, have the same the same overall need. Deliver quickly but in a secure and compliant way.
Larger enterprises have a lot of documented requirements, procedures, policies. However, the enforcement and auditing for compliance is a tedious and time consuming task that enforces a belief that security slows things down and/or is a barrier to achieving business outcomes. Overwhelmed with multiple disjoint tools, documents, outdated processes many development teams and infrastructure teams are unclear how they should be working to “be compliant.” This lack of understanding and transparency leads to a lot of re-work and delays of releases.
Whereas with start-ups and small/medium businesses (SMB) there is a desire for developers and infrastructure IT to “do the right thing” there just isn’t enough institutional knowledge or guidance to know what the right thing actually is. There is usually a lack of policy, documentation and processes because the adopted mantra is to “get it out quickly then figure it out later.” Same as the enterprise case this leads to a lot of re-work later in the process when it is much more expensive to remediate than if it was done correctly from the beginning.
What if the enterprise and start-up could have all its security and regulatory needs met at the beginning. Making security innate, not be bolted on later, means you are forcing yourself into a structure of sustainable and evergreen security. When coding first begins and the startup, or SMB, had the tools/knowledge at the beginning? Both cases would be able to save a time and money. Not to mention being able to move the mission forward instead of spinning your wheels taking one step forward and two steps back.