To ensure that ideas can be tested quickly and feedback obtained early, development, security and operations work together in the same team. Security tools are automatically integrated into every phase of the software development life cycle. The result: secure software with the speed of Agile and DevOps. Security thus becomes a cost saver and accelerator at the same time.
In order to be able to react more quickly to new challenges, companies are becoming increasingly agile and consumer-oriented. Today's customers demand the best services and features - available at any time, easy to use and secure. The needs will not become less in the future, the pace will not slow down and the complexity will not decrease. To achieve top performance, companies need to break down silos and rethink legacy processes.
Agile and DevOps are already important advancements in the software development process. They make companies faster and more capable of acting. With DevSecOps - short for development, security and operation - the next evolutionary step follows. Because united and aligned, Agile and DevSecOps achieve their common goal: the best possible customer experience and short deployment cycles.
All good things come in threes
DevSecOps represents a natural and necessary evolution of how companies can address security in software development. It automates the integration of cybersecurity at every stage of software development. From initial design, through integration, testing and deployment, to software delivery. DevSecOps is an extension of DevOps. Both methods share similar characteristics, including automation and the use of continuous processes to establish collaborative development cycles. While DevOps prioritises speed of delivery, DevSecOps focuses on security. The topic of security thus slides to the left in the development cycle in terms of time, so it is embedded from the beginning.
In the past, security was "tacked on" to the software at the end of the development cycle by a separate team, almost like an afterthought, and tested by another team.
In the past, when software updates were released only once or twice a year, this was still manageable. But with the establishment of Agile and DevOps practices, which aim for quick releases within days or weeks, this downstream security approach is no longer sufficient.
The goal is to continuously protect applications from the beginning and to shift security to the front. Vulnerabilities and security risks should therefore not only be addressed at the end, but already at the beginning and during software development. On the time axis from development to introduction, this corresponds to a shift to the left - called "shift left" in security circles.
United and aligned, Agile and DevSecOps achieve their common goal: the best possible customer experience and short deployment cycles.
Roman Hugelshofer, Managing Director Application Security, Member of the Executive Board, Ergon
Automatically safe
DevSecOps seamlessly integrates application security into Agile and DevOps processes. The deployment of secure software is automated through the use of security tools without slowing down the software development cycle. Security problems in in-house or third-party developments are thus anticipated before they occur. For example, a scanner can be used to automatically check software components for potential vulnerabilities every time a change is made. As a rule, it is easier, faster and more cost-effective to correct errors immediately when they occur. And not only in a downstream security test or shortly before go-live.
The easier to use, the better the adaptation
Despite all caution, however, it can happen that security vulnerabilities are discovered during runtime. Especially in the case of applications developed by others or open source components, there is a risk that risks will emerge or develop over time. The running live system must consequently be "patched".
Security tools such as a microgateway, which are already in use during development, allow developers to conveniently set security rules themselves not only during the construction of the application, but also when the system is live. And this without having to rely on a security professional. This is important because security tools are often not designed to be easy to use by developers. Therefore, with the right tools, everyone's security awareness is promoted and becomes an integral part of software development. Since the budgets for security tools are often spoken by the security teams, ease of use for developers is an important success factor in adaptation.
Double protection, double security
The DevSecOps approach optimally integrates security into applications. It guarantees that cybersecurity can keep up with the pace of innovation and begins to build a culture and collaboration between development, security and operations teams. However, at the enterprise level, it is impossible to apply security across the board due to older, unsupported legacy systems, third-party software building blocks or detached activities from other departments that may be outside the remit of the development teams.
As long as legacy applications exist outside the DevSecOps environment - or DevOps teams do not fully implement security from the ground up - traditional tools such as a firewall are still recommended for dual protection of applications and mitigation of attacks.
The double protection approach is widely used, as this starting point is now present in most modern organisations; especially in movements such as Open Banking, where banks with established legacy environments rely on fast and secure integration of third party applications. It is important that such measures are already planned for as part of the software development lifecycle. In this way, it is ensured during the development of the application that the rules for protection also meet the requirements of the users. The protection should be as high as possible, not noticeable and not restrictive.
Shift Left: Shifting Security
Save costs through automation
The initial effort for this automation of security should not be underestimated. Every significant change slows down day-to-day business and entails costs as a direct consequence.
But the investment is worthwhile: time-consuming manual checks and the associated error rates are reduced and both security and speed are increased.
There is no doubt that it is financially advantageous in the long term to prevent significant security incidents and resulting image damage before they occur. The ability to detect an attack and act quickly is central. In addition, DevSecOps creates a more agile system that can be launched and updated more quickly. With the involvement of DevSecOps engineers, companies can automate their security infrastructure, simplifying a time-consuming, highly technical and error-prone process.
The goal is to continuously protect applications from the very beginning and to shift security to the front.
Daniel Estermann, Product Marketing Manager Airlock, Ergon
People, processes and tools
The trio of people, processes and tools plays an important role in the success of DevSecOps. It takes a culture that recognises that there is no "us" and "them", but only a "we". Everyone is jointly responsible for the security of the software. What sounds simple requires a completely new way of thinking.
The security team must believe that developers and DevOps experts want to write and deliver secure software. The DevOps teams, in turn, need to realise that security professionals are not the ones who just say "no" and slow down innovation. Instead, they are tasked with protecting companies from security attacks and act as coaches by helping development teams set up automated security checks. In this way, developers are trained in secure programming and sensitised to any attack scenarios. Bringing together such new ways of thinking takes work, time and cultural change.
It is also important to note that purchased security tools are usually provided and approved by the security team and budget. If the purchased tools are to be integrated into the DevSecOps process, they must not only meet high security requirements, but also be optimised in terms of user-friendliness and tailored to the needs of developers and DevOps engineers. Security providers who want to promote DevSecOps must be aware of these requirements.
Came to stay
DevSecOps is now considered a modern way of product development. Adaptation is still hesitant, but ultimately the future always belongs to the brave.
The two biggest advantages are speed and security. Development teams deliver better, more secure code, and they do it faster and therefore more cost-effectively. DevSecOps makes security a shared responsibility between development, security and operations teams. "Thanks to the right tools and a shared user:inside focus, software becomes more secure and faster", is the DevSecOps motto.
This change in thinking can transform security from a brakeman to an accelerator. A prerequisite for the successful introduction of DevSecOps is the awareness of all those involved that such a project affects several areas of the company.
By shifting security to the left, companies not only increase their digital capacity to act, but also prepare themselves for a digital future in the fast lane.
| Mistake | Tip |
|---|---|
| Not enough stamina | If expectations are too high, there is a risk of being disappointed. DevSecOps is a long journey with no shortcuts. |
| Top-down-approach | DevSecOps cannot simply be imposed by management. As with any change in behaviour or awareness, it requires structural adjustments and continuous change management that combines cultural aspects in particular. |
| Unstructured approach | First identify the risks, prioritise measures and set realistic interim goals. The ideal starting point is problem areas and bottlenecks between development and security. Waterfall-like security processes should be eliminated wherever possible. |
| Benefits of DevSecOps are not recognised | Use storytelling and include every improvement in the form of a security story in the backlog, analogous to user stories. This makes implementation plannable and, above all, visible for all stakeholders. This creates transparency and trust. The documentation of role changes and the recording of mutual expectations is also central to clear communication so that the team understands its responsibility. |
| Poorly automatable security tools | Ensure that all parties have the necessary tools to get the job done. Automation is also gaining ground with security tools: control is via script or API. Graphical user:interfaces can make it easier to get started, but are poorly suited to automation. |
| Alleiniger Fokus auf Code-Analyse | Application security testing can be used to detect known attack vectors and vulnerabilities at an early stage. To prevent new or even unknown attacks, modern web application firewalls are still mandatory as additional protection. In DevSecOps architectures, this function is increasingly taken over by microgateways (e.g. Airlock Microgateway). Their security model guarantees that only those calls reach the application that the developers have explicitly assessed as valid. |
Blognews directly in your mailbox
The Airlock Newsletter informs you continuously about new blog articles.