DevOps and Security – how to build more than another stage into software processes

No-one wants to make insecure software. We want to make robust software that fulfils a need, achieves a goal and does it elegantly. However, that aim can be harder to meet when it comes alongside time pressures, the rush to deliver updates and the constant clamour for attention. For developers, working code is always the first priority.

This misses out on one of the biggest challenges for developers – making sure that the code delivered is secure. There’s a marked discrepancy between the wish to have secure software and the responsibility for delivering it. For example, MongoDB announced research into security in early 2020 where developers were surveyed about their approach to new applications. A massive 92 percent of developers stated that they take appropriate precautions when developing applications, while 47 percent agreed that the security of data was the top priority when procuring new solutions.

SEE ALSO: How security keeps up when developers drive open source

However, only 29 percent of developers agreed that they had the most responsibility when it came to the security of their own software; those surveyed pointed towards IT security teams, operations departments or other specialists instead as responsible. Yet, who else is best placed to implement security from the start, so that problems don’t have to be fixed in production or reworked later in the software development life cycle (SDLC)?

Security – bolt-on or built-in?

Behind this, there is a fundamental split in approach that software developers have to think through around security. On one side, you have the view that security is a phase to go through in the SDLC before things go into production. This involves checking that code, applications and infrastructure are checked before they head into production. If any problems come up, then they can be passed back to be fixed.

On the other side, you have the argument that security should be embedded throughout the SDLC. Rather than it being a phase to go through, security tools are available to developers throughout the development, coding, testing and implementation phases. This does not mean providing the tools to the teams, but how to truly integrate security into those developer workflows and processes.

For the developers involved, both approaches should result in the same thing – secure code and applications that can withstand the rigours of working life. However, the routes they take to get to that destination are very different.

Bolting on security as a phase in the DevOps process, or after, misses out on the bigger picture approach that security can provide across code, clouds and infrastructure. It can also fail to flex with the new platforms that developers want to take advantage of, like software containers. Instead, it acts like the traditional security function approach of blocking or stopping software from being released. While this might be understood, it’s not the most collaborative approach and it can even be subverted due to goals not being aligned.

Instead, it is worth spending the time to build security into the development process. This involves integrating security tools directly into the continuous integration and continuous delivery pipelines that developers have in place. This can be achieved using the APIs and plugin architecture present in tools like Jenkins, Bamboo, or Circle CI, and then using these tools as and when any software asset is created. More importantly, these tools should be practically invisible to the developers or testers themselves; they carry on working in their preferred environments and simply consume the resulting data.

Taking a collaborative approach to security

This is particularly important when it comes to managing security best practices and vulnerabilities during the development process. There are plenty of best practice frameworks available from organisations like OWASP and ISC2 that can be used to improve software quality, while software vulnerability tools can be used to automatically scan for any issues in software components or code. By automating the process and turning this into an API call, developers can carry it out for themselves at any point during the SDLC.

If an issue comes up, then it can be flagged automatically and added back into the queue for a developer to investigate and fix. This makes secure code and application development into a standard part of the SDLC, rather than being a stage to go through towards the end of the process when everyone is straining to complete delivery.

SEE ALSO: Five security principles developers must follow

This change is also more conducive to collaboration between teams. Because security teams provide tools and support to developers, they are not in the way of a successful deployment; instead, they are trusted colleagues that can help speed up projects and remove obstacles. Ideally, security teams should be embedded into development and deployment striving to understand and achieve the same goals.

Over time, security should be part of the whole SDLC from beginning to end, shifting as left as possible in the process. This helps everyone achieve the goals of delivering secure code and applications. Rather than being somebody else’s problem, it becomes everyone’s responsibility. By taking the right approach and building security in from the beginning, everyone involved in delivering software can play their part from the start.

The post DevOps and Security – how to build more than another stage into software processes appeared first on JAXenter.