The DevSecOps process
While time to market is driving the adoption of continuous integration (CI) and continuous delivery (CD) practices within organisations, security has to be a top priority for application owners and their development teams.
Releasing an app that has coding flaws and inadequate defences creates an opportunity for anyone to change or insert unauthorised code that could do anything from stealing a user’s information to repackaging the app function and making it their own.
Allowing any unauthorised person to make such changes to an app through a lack of security will damage a customer’s trust in both the app and the developer, which could lead to loss of earnings and brand damage.
Does your vendor run security checks on their products?
Unfortunately, in the usual software development life cycle (SDLC), where security teams are consulted in the last stage, velocity in reduced delays can be caused while the entire code of an app is trawled through for weaknesses, or to save time, this process is curtailed altogether. Neither of these options are good for business.
Instead, developers need to take a more holistic approach to security — DevSecOps. A well thought out DevSecOps mindset ensures that security is considered at every stage of the development process and is everybody’s responsibility. The benefits of such an approach include improved operational efficiencies and a greater ROI from the existing security infrastructure.
Implementing DevSecOps
The most important element of implementing an effective DevSecOps strategy within an organisation is education. Making sure that everyone involved in the development of the app is on the same page regarding security is key, because even just one person not complying with the process can create holes in security. This means making sure everyone is aware of their responsibilities and what the benefits of DevSecOps are overall, as well as ensuring that all teams – development, IT and security — communicate effectively.
There will likely be many in an organisation that view security as a detraction to app development and the application itself. The perception is that it increases timelines, decreases app performance and negatively affects the overall user experience. While some of this might ring true, there needs to be a discussion around the various trade-offs and how implementing DevSecOps is of benefit to the company as a whole, to make sure everybody is on board. And this means everybody, not just the developers but also product managers and business-level teams.
One way such an education can be achieved is through seminars demonstrating how vulnerabilities can be exploited in the real world and conveying what the risks are. Providing real-life examples brings home the magnitude any security lapses can have on a company’s reputation, revenue and customer base. This will then hopefully foster an environment where a development team proactively anticipates potential security requirements.
DevSecOps: how can companies embrace it?
DevSecOps tools for the job
It’s no good getting everyone in an organisation to realise the benefits of implementing security measures throughout the development process if the tools aren’t there to be able to make it a reality. Examples of such tools include static code analysis, which can be run each night to highlight vulnerabilities in non-running code submitted to the team’s local repository, ready to be worked on in the morning.
Then there are code protection solutions, which can be placed into the SDLC to enable developers to identify risks during development and mitigate them by inserting a corresponding guard. Leaving this process until the end of the SDLC is still a valid approach, but often leaves the team responsible for security playing catch up before release — forcing them to identify every vulnerability at once in order to meet a project’s release deadline.
Where DevSecOps doesn’t work
Ideally a DevSecOps process should be reserved for applications running in a zero-trust environment, i.e. applications that are deployed into the outside world, via app stores or available on the public web.
Finally, legacy applications are not usually appropriate to be put through DevSecOps as the source code is often not readily available or has been written by a third party.
As such they should instead be assessed by an external team using a penetration test to find any serious violations, which can then be remediated when resources and time permit.
How DevOps works in the enterprise
Security is everyone’s concern
Security must be integrated into the agile development process. By doing so, organisations will be able to address security threats more effectively and in real time.
Making security a shared responsibility between development, IT and security teams should help change the perception that security is a burden and slows down the agile process — in addition to sensitising the entire team to the need for speed and agility to deliver new solutions to market.
