Hello everyone and welcome back to the Cognixia podcast. Every week, we dig up a new topic from the world of emerging digital technologies and share insights, ideas, information, stories, and more. We strive to inspire our listeners to learn new things and update their repertoire of skills to stay relevant and continue growing in their careers.
In most organizations, right about the time when the development and operations teams feel they are doing an excellent job of accomplishing tasks and they will easily finish the project before time, there appears out of nowhere a person who makes everyone’s eyes roll – the security guy. This person will point out the flaws and the bugs, the loopholes and the vulnerabilities in all the builds, and just when you thought the client was going to be extremely happy with the team for finishing the project well before time, you now look at a possibility of having to ask for an extension, because all the things the security guy pointed out is going to need a few weeks to correct. No way will you meet your deadline. Why did the security guy have to show up when everything was going just fine?
We have all wondered this at some point, haven’t we?
Oh, and the saga doesn’t end there. After this, out of nowhere, there is an external QA specialist the client sent to double-check everything and check for security. To make matters worse, the security tests need to be done manually.
Is there ever an end to this?
Well, to be honest, over the years there has been quite a transformation in software development, making the process a lot more agile and even automatic. But when it comes to security, we still lag and things haven’t changed all that much.
DevOps is giving way to DevSecOps, but the pace at which this is happening isn’t quite heartening to see. Another development in the space is Security-as-Code, which works in tandem with DevSecOps, and that is what we will be talking about in today’s episode.
While there is no doubt in any of our minds that security is an integral part of the software, we usually tend to leave it for the end of the SDLC, by which time it is already too late to handle such a critical aspect of the software. This will cause delays in your software development timelines. Since we are all conditioned to believe that security is a one-time thing, most times nobody bothered to automate the security testing, so you’re stuck with doing everything manually, which only takes so much more time than automated testing.
To change this scenario, experts suggest two critical steps. First, shift security to the left. Meaning, why should security be added as an afterthought? Why should security be incorporated after everything else is already completed? Instead, move security steps to the left, making it an integral part of the SDLC, and not a step to be taken after the SDLC is complete.
Second, invest in automation. Manual work is often very tedious, time-consuming, prone to errors, and risky. Instead, put in the effort to automate the security aspects and testing. Automate the process of defining policies, security test cases, etc., and save both time and resources, plus, no errors!
When you do both these steps effectively, you can say you have transitioned from DevOps to DevSecOps.
So, what is this noise about Security-as-Code?
Shifting security to the left as experts suggest, is a lot easier said than done. It would require security checks and tests to be added at every stage of the SDLC. This is difficult, no doubt, but not impossible. And, it is totally worth the effort. While introducing these checks and tests, it is also important to ensure that there are no unnecessary costs or delays. This is roughly the idea behind Security-as-Code.
To define it better, we can say, “Security as Code or SaC is the practice of building and integrating security into tools and workflows by identifying places where security checks, tests, and gates may be included.”
To get the security checks and tests running on automation for every code commit, the security policies, tests, and scans would need to be defined beforehand as code in pipelines. If you look at it in-depth, you realize that Security as Code is in a way a guide on how to achieve DevSecOps.
So, won’t these additional steps of security at every stage of the SDLC slow things down? Actually, no. Contrary to popular belief, deploying security as code will accelerate the SDLC. Wondering how? Let us explain.
First and foremost, when security is shifted left, the requirements and checks would be defined at the very beginning, so the possibility of rework is almost ruled out. With everything getting automated, every incremental code commit can be secured.
Next, since with Security as Code security is codified, there is repeatability, reusability, and consistency in the SDLC. One could observe the development velocity increase. Manual security testing is eliminated, security components can easily be reused in multiple instances, and the process is less error-prone than ever before!
As a result, the team is saving time, the resource utilization is so much more optimized, and it all can be seen translating to cost-savings. When the checks and tests are automated, any potential vulnerabilities in the software at any point would be immediately fixed as they get caught early on. Overall, by embracing security as code, one can see the resource footprint of the software decrease to some extent.
So, what would be the key components of the Security as Code?
Security as code would have some important components that would work towards security shifting left and bringing in automation at every step.
Components include:
One, automated security tests
Two, automated security scans
Three, automated security policies, and
Four, Infrastructure-as-Code security
Embracing security as code or DevSecOps doesn’t happen overnight. Shifting left and automation are considerably easier said than done, with each having some challenges on the path to implementation. However, a good starting point to be truly successful in this venture is to begin by changing the mindset of the team. Unless the mindset changes, changing the protocols and SOPs will not make any significant difference.
A good way to go is to follow the Amazon path. At Amazon, there is a famous adage that everybody is expected to abide by – “Security is job zero”. Show the team the impact that Security as Code can have. To motivate the team, show them how embracing security as code would be so much easier, quicker, and simpler than reworking and rewriting at the end of the SDLC. For instance, changing the design of a garment you want tailored is so much easier to do before the cloth has been cut but it would be so much more challenging to alter a garment after it is completely stitched and ready-to-wear. It is the same case with security as code.
At the end of the day, security as code is all about automation. Have the team write out the automated tests as early as possible in the SDLC, and set up all the tests, scans, gates, and everything at the soonest possible.
So, in a nutshell, and I am sure we have said this before, security should never be an afterthought for any organization, it should be job zero. Cybersecurity should be given its due importance in every SDLC and should not be taken up as a mere formality. The more you invest in automation and weaving security in every strand of the software’s fabric, the happier you will be as the SDLC moves forward, and even happier the customers and users.
What is your organization’s take on cybersecurity? What can your team and organization do differently to improve its security posture? Is there something you are already doing differently that has enhanced your cybersecurity situation, making all your software and systems more secure and less vulnerable? Hit us up on any of our social handles and do share your thoughts, we are all ears!
With that, we come to the end of this week’s episode of the Cognixia podcast. We hope we were able to help you learn something new and it could be useful to you in some way. We will be back next week with another exciting & interesting episode of the Cognixia podcast.
Until then, happy learning!
