How to introduce a new security rituals into an existing software development lifecycle
It seems fitting that I'm writing this blog post in May. Early spring is the season for many exciting things, including some of the world's most prominent developer and cyber security conferences. Whether you're a leader in the engineering or security teams, we're bombarded with new approaches and tools. Vendors are marketing to us, books are released, and conference talks feature throughout our news feeds.
It's not surprising, then, that from time to time, we stumble upon a new approach, ritual, process, or tool that can potentially improve our software's cyber security and can be embedded into our software development lifecycle (SDLC). Of course, we want to try it.
Before you excitedly sign a purchase order for a new tool or start developing your internal process documentation and playbooks, take a breath.
If you want this to succeed, there are some things you need to know.
You can't pack other people's bags
I'm a big fan of analogies, so bear with me while I explain what I mean in simpler terms. Imagine your team's software development lifecycle is like a suitcase.
Some teams will have it perfectly packed and arranged
They have a place for everything and know why everything is there. There is no wasted space here. For every item they have added, they understand that something else will have to give. After all, whether you want to or not - there's only so much you can fit in.
Some teams aren't quite there yet
At best, they have some well-managed elements and some understanding of what they want to achieve. At worst, they have chaos. Things have been stuffed in randomly and without thought for the other items in there.
Mature or not, the end result will be the same
Now imagine for a second that you want to put something into the bag as an outsider to this process.
In our organized and mature team, that change will immediately impact what is already there and what the compromises will be if this change happens. They may not be happy that someone else has packed items into their neatly curated suitcase.
In a less organized team, they may put it in without discussion and find out the impact over time. The response to this may be slower and gradually change from curiosity to frustration and resentment - depending on what happens.
Both could be better.
Understanding purpose, outcome, and impact in the SDLC
In an SDLC, every element has a purpose, an outcome, and a set of impacts.
Purpose
The reason this action needs to happen.
Outcome
The result of the process, tool, or approach - often the input of another stage of the lifecycle.
Impacts
The influence this element will have on
People
Money
Time
Security
Performance
Quality
A new element's impact must provide a concrete, useful output. The purpose - and benefit - must outweigh its impacts on the rest of the lifecycle.
Too little benefit, lack of useful output, or unclear purpose can lead to resentment and confusion.
Too much impact and the same will happen.
As you can see, framing your new addition in terms of these criteria is not as simple as just handing over the tool and wishing the team luck.
Strategies for successful change
So how can you navigate these criteria and help implement new processes, tools, or rituals in a software development lifecycle?
You can’t change what you don't understand
This probably seems obvious, but if you are hoping to influence or change something, it's a great idea to understand it first. If you aren't actively part of the software team or using these processes day-to-day, now is the time to learn.
Spend time with your engineers and walk through the processes as they currently stand. This isn't a time for you to suggest changes, though. This is a time to listen and to learn.
Questions you should be asking:
What tools and processes are currently in this software development lifecycle?
Who runs them? How much time does it take?
What is an acceptable completion time for each phase? This is especially important for tools embedded into deployment pipelines.
What is currently working well?
What is hurting the team, and what would they change if they could?
This process is valuable, not only for you as you prepare to weave cyber security through it, but also for your relationships with your engineering teams. Security is about collaboration, which starts with understanding and empathy.
Start with experiments, not solutions
Engineers are practical people and also slow to trust. They know that even the most reputable companies' most popular tools will behave differently when deployed into their environment.
Therefore, the rollout of a new process, tool, or ritual needs to start as an experiment. By doing this, we create room for the engineering team to provide feedback and assess it from their perspective. It also gives you time as a leader to understand if this is the right approach. The last thing you want to do is spend your social capital with the team on something that causes pain or damages the relationship.
Like any experiment, you need to start with a hypothesis and some criteria that you can measure. Additionally, you will need an understanding of what success and failure would look like.
For example, an experiment for rolling out a source code review tool into the CI/CD pipeline would need the following.
Hypothesis:
Using a source code review tool in the CI/CD pipeline would:
Allow the team to review all source code on commit
Identify cyber security vulnerabilities in our specific language set and technology stack
Reduce the time taken to check code for cyber security issues
Criteria:
Run time: Tool must run in less than 10 minutes so that the deployment pipeline is not compromised
Run frequency: Tool can run on every commit and be triggered from our existing tools
Output: The tool output can be automatically raised with engineers and also recorded in our ticketing or issue tracking system
Exceptions: The tool can be configured to allow exceptions that are specific to our environment
Experiments will typically run for between 1 and 3 months to allow for testing over a sustained period and a wide range of development milestones. In the best case, experiments include brand-new code and projects and legacy systems to ensure the range of the capability is understood.
Create a rollout plan with the engineering team
If the experiments succeed and you (and the team) are satisfied with the outcomes, it's time to roll out.
Rather than just turning things on and calling it a job well done, consider the following.
Training
Provide training for all engineers using, operating, configuring, or otherwise interacting with this process or tool. Ensure this links to clear explanations of the tool's purpose, outcomes, and impacts from above.
Support
Have a plan for if things change, if there are issues, or if the team needs help. If they find it is no longer working, and you don't have a clear support system, the process or tool will be removed or avoided. Once this happens, getting it back in takes more than just flicking a switch - it takes negotiation and relationship repair.
Review
Tools and processes that work now will only be the right solution for a while. Have an annual process for reviewing the effectiveness of the tools and processes you have in place. This gives everyone involved a chance to address issues and identify any changes that need to be made.
Collaboration is the key
No matter how big or mature your team is, introducing new elements to an existing software development lifecycle can take time and effort. Remember, however, you can make these changes together by collaborating with your engineering team and focusing on the purpose, outcome, and impacts of the proposed changes.