If you are a developer or a security admin shifting left is a phrase you may have heard but what does it mean practically?

• Organisational and procedural change
• Incorporating a security first approach as part of your approach to development
• Incorporating security checks and gates as part of your development to production pipeline i.e incorporate security as early as possible.
• Getting Devs to think like security admins and security admins to think like developers.

However most of the time you come across articles on shifting security left it’s focused on the developer point of view focusing almost exclusively on the dev pipeline so addressing : “Incorporating security checks and gates as part of your development to production pipeline i.e incorporate security as early as possible.”

For example https://cloud.google.com/solutions/shifting-left-on-security states as it’s key takeaway to design a code pipeline that accumulates trust throughout the progression of the build." https://docs.microsoft.com/en-us/devops/develop/shift-left-make-testing-fast-reliable this one focuses on shifting left to make testing fast & reliable.

But what about DevSecOps I hear you cry? Yes that is an integral part of shifting left. I currently like this explanation of DevSecOps https://www.redhat.com/en/topics/devops/what-is-devsecops but yes it’s a developer pov and quickly jumps into talking about the dev pipeline .

If you’re a digital native or Greenfield with no legacy organisational considerations or you are not a regulated industry then I’d say it’s actually relatively easy to shift left and embrace DevSecOps as intended as no legacy organisation and agility to adapt whatever organisation is in place .

However this post is aimed at more traditional and regulated industries where it’s not that simple to embrace as basically silos do exist and someone is accountable for the security posture.

Being responsible and being accountable are not the same. I tend to think of responsibility as being more task oriented and the person(s) who actually complete the task(s) has responsibility for that task determining how it should be completed . Accountability I think of as being ultimately the one who has overall ownership for the thing the task(s) feed into , is the person who is answerable with respect to the overall outcome and is empowered to make decisions that affect this . Key here is that responsibility can be shared but accountability cannot! If you’ve ever used a RACI matrix you’ll have come across this and there are plenty of formal definitions re accountability & responsibility. For example devs may build a thing but ultimately it’s the Project manager who has to explain to the sponsor of their project re the outcomes etc. From a security Admin’s point of view they are responsible for the security posture of the company, application etc . ( yes I know that this is in reality the CISO but it tends to be the Security admins responsible for executing so for illustrating accountability versus responsibility with the personas I felt I could get away with that) . It’s the Security Admin who will be explaining to the CISO who in turn will be explaining to the CTO and CEO if a breach has occurred. It’s not the devs who built the application or the ops team who configured the infrastructure/platform. Understanding that helps to understand why Security admins err on the side of caution and thus why it takes time to move at the pace the devs would like.

With that nuance of accountability and responsibility in mind I’d argue that we should focus on shifting even further left looking at the organisational changes needed to make it work as intended and to understand a Security Admin’s motivation.

I’m not going to discuss zero trust , securing your ci/cd pipeline, binary authorisation or any of the typical topics shifting left on security focuses on as there are lots of articles that go into detail on the tooling but I am going to discuss the people side and take a Security Admin’s view on this as ultimately it’s the Security Admins who have an implicit affect on the speed to production. Before you disagree ( which you’re perfectly able to do) think about the time you tried getting past a security admin who is not happy about the security of your app! So I’m adding another bullet point to my list of what does shifting left mean practically :

• Making your Security Admin happier earlier

We should make the organisational concerns the first thing you do when it comes to shifting left . Get that right and it all falls neatly into place.

Devs and Security Admins need to understand each others motivations. Why does your Security Admin usually start off with asking what are the risks ? Why do your Devs want to deploy ever faster and faster? If there is no understanding between the two not even DevSecOps will help.

DevSecOps should absolutely be an objective however there will still need to be sign off from the person who is accountable yep the Security admin. So ensuring they are involved and understand how you integrate security into your pipeline really is important as they want to know what threats the guardrails that are in place mitigate against. If they are involved in influencing the guardrails via having oversight and being involved in the decisions that affect:

• Security of developer workstations
• How security testing is incorporated
• How secure coding techniques are employed use secure coding checklists (The direct owasp link is here ) and Security plugins for your development ide e.g https://devdojo.com/yoda/top-vs-code-extensions-for-application-security-in-2021
• That the pipeline ( code repos, build , ci/cd tooling) is as secure as can be
• Least privilege is implemented
• Security posture of Upstream repos and libraries
• Authentication & authorization is configured
• The platform the build and ci/cd tooling is deployed to is appropriately hardened
• That the controls & guardrails appropriate to each stage of deployment are implemented as expected

Then there shouldn’t be a significant pause due to the security admin needing to validate before it gets to production. After all they’ve been involved in the process that goes from Dev workstation through to deployment and thus will understand what controls have been implemented and precautions taken to prevent comprises.

Ideally the sign off process may well end up not being needed as the quality checks as the apps go through the pipeline are understood by everyone involved .

The intersection of security with operations is equally important , who has access to make changes to the network? Configures access to trusted repositories? Sets up firewalls etc . This post is already quite long and I may one day talk about this integration in more detail but today is not that day. tl;dr security needs to understand how the platform that the application is being deployed to has been configured what threats the guardrails in place are mitigating against. The same issues I am discussing re integration with Devs applies here too.

Trust - Devs and Security Admin’s need to trust each other. By understanding each others motivations this helps to achieve that trust and assume best intentions . Having trust encourages Devs to reach out for help when it comes to security earlier as they understand that Security Admin’s aren’t just there to block everything and slow things down so reaching out isn’t a precursor to a security Admin putting blockers in place because you raised a concern. They’re there to help get your application into production safely.

Security decision makers need to be accessible . A decision maker when it comes to taking a posture on a security related issue should be embedded with the Devs . This is how DevSecOps should really happen as you can’t expect your Devs to have depth in every domain.

But it doesn’t end there Devs need to think like a Security Admin and Security Admin’s need to think like Devs that way DevSecOps can be realised . Without empathy & an understanding for each other’s domains it’s just Box ticking. Devs need to want to create secure Apps and Security Admin’s need to want to accelerate the time to production.

Everyone in the development process needs to be responsible for security : Auth and authz, least privilege, ensuring services only communicate with what they need to, not exposing security keys , tokens , passwords , protecting against vulnerabilities are the very basic a developer needs to think of. A quality check needs to occur to help . Devs should understand threat modelling to help them when designing their apps.

The cognitive overload of focusing on the functionality as well as considering threat models can be difficult so helping to alleviate that is really important and is where Security Admin’s & the embedded Security SME in the team need to step in to help.

There will always be a trade off between speed versus security. Trying to avoid exposing sensitive data or avoiding a ransomware attack or if you do succumb to an exposure or ransomware attack being able to recover are top of mind for a security admin . By having everyone be concerned about those issues by tackling the people side and shifting that left there is more likelihood of a happy middle ground being reached where the priorities of the Dev team and Security can both be met by working together as a team ( yep DevSecOps) . This doesn’t mean The two no longer exist as separate entities as the Security Admin is accountable for the Security posture and the head of development is accountable for the Application.

If you get the people side right as new Dev teams are spun up to focus on new projects those Devs will ask for security to be embedded , security won’t need to ask to be included in the team 🙂

This approach also makes dealing with issues in production easier . Take the principle of least privilege this implies not everyone can do everything so at production your controls need to enforce that which also means the developers will not have access to that environment. If Security Admins or who ever has access to production understands what the application is and how it’s put together if an issue occurs in production they are more likely to be able to mitigate faster and understand how to rollback to a known safe version while understanding the implications of that decision.

If there’s a vulnerability having team members who think like Security Admin’s helping to take appropriate mitigating actions quickly is invaluable. Having your Dev team pull patches & create new builds without being asked to take action to mitigate is the state where shifting left with empathy places you.

Tooling is important but unless you actually encourage a security first mindset there will be a bottleneck as you will need to get your application signed off by security. If you deal with any potential issues earlier the path to production is reasonably friction free and the sign off process is accelerated as Security has less validation to do before release to production as they trust the Devs have done the right thing as they know what mitigating techniques & guardrails have been taken during the development pipeline and what threats they mitigate against so they have no need to dig into everything which takes time.

Another benefit of shifting even further left means that adapting parts of the software development pipeline and how you manage the software lifecycle becomes easier to do. Want to swap GitLab for GitHub ? That should be a decision that can be made quickly as you have a Security decision maker embedded in the team who will have been part of the process that is looking at the transition and due diligence is implicit.

Thus to be able to shift left further with empathy so you actually accelerate the time to deployment not the time to get to security sign off which is what the typical shift left achieves you need to make organisational changes to allow Devs & Security to:

• Understand each others motivations
• Trust each other
• Think like each other
• Embed a security decision maker within your Dev teams
• Everyone to take responsibility for security
• Do all the things that shifting left Security require you to do to Incorporate security checks and gates as part of your development to production pipeline

Doing all the above allows decisions that affect Security to be pushed left and taken earlier not just pushing the decisions that have already been made left. This approach encourages agility.

So shifting left now goes from something like this :

To something like this:

Organisational change is hard but without tackling that head on it will be an impediment to achieving agility and the ability to adopt and take advantage of the paradigms of working in a cloud native world.