Implementing the DevSecOps methodology ensures safer and more robust applications. Successfully doing so, though, is the result of a gradual journey consisting of small steps through which the importance of security is first explained to developers and then spread throughout the organization.
Many companies have a large team of developers and aim to implement the DevSecOps method to solve the security problems they encounter in their applications but fear the repercussions this can have in carrying out their daily work.
Through a practical approach and personalized support, Sorint.lab builds, together with the client, a path to approach DevSecOps to have the best strategies, involving workshops and training, to bring developers and IT security figures closer together to create, finally, that operational alchemy necessary for the metabolization of the pillars of DevSecOps.
Without DevSecOps applications are less secure
No company is free from security problems. In some cases, an internally developed application can be vulnerable, putting both the company and its customers at risk. The goal is always to create more secure applications; but in the absence of the DevSecOps method, when developing a new application it is easier to find vulnerabilities, even at a critical level, which are often the result of a lack of overall vision of security upstream of the project, i.e. in the design phase.
How to implement DevSecOps: the two steps
It is important to consider that the implementation of DevSecOps is not, in reality, a project that has a beginning and an end, but is a process: it means reworking the organization of development work so that it introduces new paradigms and new figures regarding security and that all this is constantly evolving.
There are three stages that Sorint.lab involves in bringing companies closer to DevSecOps
The indispensable training for employees
The first step is the organization of workshops dedicated to developers, which can be both specific, for example regarding a specific programming language, and generic for new hires or for those corporate figures who do not have a high level of seniority.
Increasing safety awareness in a practical way is essential: workshops must leave the person with one or more tools, introduced on a theoretical level, with which they can practice for a few hours a week
The integration of tools for DevSecOps
In cases where a CI/CD pipeline is already foreseen
to make development rapid and automated, it is central to focus on the development tools used every day, aiming both to increase the quality of the tools and to integrate, into the pipeline, a series of tools which are the heart of DevSecOps.
Through these tools, a developer can be immediately notified of a bug introduced while working on a project: in that case, the change does not go into production and the programmer receives feedback. At that point, it can either choose to register an exception or work on the code to correct the problem.
The tools to be implemented work on different areas: there are tools that control the code, looking for vulnerable patterns, while others monitor related third-party software.
Organizations must aim to secure used software and dependencies, before discovering, for example, that those dependencies have not been updated or have been found vulnerable, thus effectively making the company itself vulnerable.
The importance of the threat model
A third phase of the introduction of DevSecOps concerns the design phase of an application. At the beginning of a project it is important that a risk assessment is carried out before working on the code. Even at this stage it is imperative that the voice of security is involved, to know the possibilities through which a given piece of code can expose the company to risks: it is the so-called threat model.
It’s crucial for:
- discuss potential risks
- know the appropriate mitigations and what measures to implement
- introduce appropriate checks to measure the level of success of the measures implemented during the mitigation phase.
Today a software cannot ignore a threat model.
DevSecOps metrics
Finally, since DevSecOps is an approach that is gradually introduced in the company, it is equally important to employ metrics that can allow the organization to evaluate itself independently and to understand, essentially, what the existing situation is and what the next objective is.
There are no absolute metrics that apply to every company in the same way. An example of an applicable metric concerns the number of corrective maintenance interventions performed in a given period following the introduction of DevSecOps vs the number of interventions before introduction. Or the availability –or conversely the deficiency – of a specific competence with respect to a specific IT security topic, which may indicate, therefore, a poor ability of the organization to respond to situations of a certain type.
Sorint.lab has applied the dictates of the DevSecOps method itself: it knows them directly and therefore can support companies to gradually integrate this methodology so that the entire team of developers is aware of how to work and security experts are involved in the projects right from the design phase.
DevSecOps is not a project like any other. Sorint.lab helps its clients in configuring the necessary steps and measuring the impact they are having in operation to strengthen development processes and reduce vulnerabilities.