4 min read
One of the big things we’ve learned since starting Kosli is that engineers often struggle to define an SDLC for compliance purposes. That doesn’t mean they don’t know how to deliver secure, quality software. They’ve just never had to actually define a process for how they do it.
Perfectly capable engineers can spend years shipping great products and features without ever having to properly define and standardize their SDLC. But that changes when they move into a regulated industry, or are faced with achieving a security standard like SOC2 or ISO27001.
View Secure SDLC Process template
The trouble with regulations and security standards
Software delivery teams in regulated industries, and non-regulated teams trying to achieve compliance with a standard, find that the expectations on them are unclear. No precise criteria are specified for how software should be delivered to achieve compliance.
There’s usually some vague language from the regulator, or in the appendix of the standard, about “ensuring that controls are met” or something similar. It leaves a lot of room for interpretation and this creates a lot of uncertainty. Most times, the steps experienced engineers have been taking throughout their careers are more than adequate.
But, without specific instructions that define an SDLC that will meet the demands of the regulator or standard, it can feel like guesswork. Is what we’re doing good enough? What steps should we include? I think this is a secure way of developing software, but what does the auditor think?
Developing Kosli’s open source SDLC template
In the days before Kosli, our co-founders were DevOps consultants in industries with lots of regulatory pressures. Typical customers included banks, automotive companies, medical device manufacturers, telecom providers - industries where you have to be super careful about the software you’re deploying.
And we had a lot of success implementing DevOps and CI/CD best practices in these safety critical environments. We learned that these types of industries can benefit from automation and increased deployment frequency without incurring extra risk. In fact, and this is maybe somewhat counter-intuitive, we found that speed and automation, especially in areas like change management, actually reduced risk.
Along the way we developed a secure set of software development practices that form our open source SDLC template. The steps we describe for build, process, and runtime are the result of thousands of hours of successful consulting in the most safety critical environments.
What regulations and standards actually mean for the SDLC
Something else we discovered is that it doesn’t really matter which industry you’re in, or which standard you’re following, the demands on you are basically the same: define a secure SDLC, implement it across your team, and then provide the evidence that you’re following the process you’ve defined.
We know from experience that our SDLC template will satisfy the demands of any industry or standard. It’s good for embedded software, cloud, ISO standards, SOC2, or whatever else you’re looking to comply with. So, if you’re struggling to define your process, we recommend that you fork the repo and make the tweaks and amendments required to suit your needs.
Embracing automation for speed and compliance
Of course, our open source template only deals with the first part of your regulatory obligations - defining your SDLC. The implementation is on you! But we can help with the last part of the compliance puzzle - providing the evidence that you’re following your process.
It’s important to understand what this really means. Many people assume that it requires a change management process, that you must introduce gates to your CI/CD pipeline and give your developers manual work like evidence gathering, change advisory board meetings, and sometimes even wet signatures!
None of this is true. Not even for medical devices. To repeat, the demand in all of these regulations and standards is actually quite simple - define a process and prove it’s being followed. You will not find anything - even in the FDA guidelines - that asks for meeting minutes and manual sign offs.
Using Kosli to ensure Continuous Compliance to production
Once you have your SDLC defined and implemented, all you need to do is plug Kosli into your pipelines and all the evidence you need for automated compliance is gathered and stored.
You don’t need screenshots for test results, or any other manual evidence gathering for change approvals. By implementing our SDLC and using Kosli to prove that you’re following it, you can unlock the benefits of continuous delivery to even the most safety critical environments.
