When talking about good practices for the development, implementation and deployment of software; we bump into the concept of CI/CD environments.
They collect criteria that usually we use altogether and probably because of that; there are people who use it indistinctly, as if they were synonyms, although they are more complementary concepts than anything else.
Los mismos recogen dos criterios que a menudo se usan de manera conjunta; e incluso hay quien los trata como sinónimos, si bien son más complementarios que cualquier otra cosa.
Let’s check their similarities, differences, and the final keys that help you choose the best option for managing vulnerabilities in your CI/CD environments.
CI/CD Environments
First of all, we must understand that CI/CD environments comprise not two, but three concepts. They are Continuous Integration (CI); Continuous Development and Delivery Continuous (CD, for both). That is, the abbreviations CD in this equation are used interchangeably for Continuous Development/Continuous Delivery.
So, the integration of the three of them helps us to create and deploy flexible applications for the management of our digital environments and infrastructure. However, the combination of CI/CD by Continuous Development brings different results from those with CI/CD combination by Continuous Delivery; especially in the regards of vulnerability management.
Let’s see step by step what they mean and imply separately in terms of protection and security.
Continuous Integration in CI/CD environments
First of all, let’s start with Continuous Integration. This is the ability to create, validate and deploy changes and test them automatically over an already established network architecture. The idea of this concept is to save time and efforts when developing applications; and trying to make them fit into a pre-established framework.
In other words, the Continuous Integration allows the coupling by phases of application as every one of them are developed in order to correct; improve and rethink them if necessary when we still are in the creation process. Same, it helps to isolate possible problems to a single stage without compromising the integrity of the final prototype at the time of its execution and deployment.
Continuous Delivery in CI/CD environments
Following, we come across the Continuous Delivery in CI/CD environments. We can define it as an extension of the Continuous Integration that responds and assures the expeditious release of changes in your applications.
This means that in addition to delving into the process of releasing applications by sections; you also create intrinsic policies and processes to deploy the application with the simple action of a click.
From a more theoretical point of view, the Continuous Delivery in CI/CD environments; enables you to schedule your application launches according to the specific needs of your business.
In any case, the Continuous Delivery must contemplate as a starting point the partial launching of small advances so to attend contingencies in case of having them.
Continuous Development in CI/CD environments
Finally, we find Continuous Development in CI/CD environments. This last concept takes your production further. This means that Continuous Development contains a small distinction that marks the total difference in CI/CD environments: Automation.
Up to this point, we have passed through the stages of development of applications in CI/CD environments taking as reference the intervention of the administrator in each stage. In other words; it is the administrator who makes the decision to continue with the development pipeline.
In the case of the Continuous Development; each change is automatically implemented without human intervention, after each successful trial.
Now, how do you do with improvements in case that the application needs them? Simple: Failed partial tests throw lights and alerts on the areas of improvement in any of the dependencies before continuing to the next.
So, the main advantage of Continuous Development is that you can better program your launches since you will be able to speed up your processes at each stage; give some slack to your developers; and verify the correct functioning minutes after running the corresponding test.
Event 1. New Vulnerability
If a new vulnerability strikes, we have to verify if it affects or not one of our libraries, and if it was disclosed. Further decisions will depend on this.
Event 2. Impacts of such vulnerability on our systems
In the case that in effect, some functionalities of our systems are threatened or compromised with the new vulnerability; then the next step is determining the full extent it has. Vulnerability reports are useful to do so.
Once we document this, we will be able to take one of these decisions:
- Mark vulnerability as non-exploitable in our systems. With this action, we can deal with it afterwards.
- Proceed to update the affected system with the respective patches if they exist; and according to the criteria set out below.
Event 3. Security Patch Management
Once we determine if the patch proceeds, we must take into consideration the following scenarios:
- Is it more profitable in monetary terms to implement the patch, or to assume the exploitation of the security flaw?
- In case it results more profitable to implement the patch, determine if the solution is compatible with our system functionalities.
In both scenarios, we must determine how much systems are still vulnerable once we manage the security patches.
Also, at this point, it is good to remember that many times security patches are limited to the newer versions of system. So it is good to check out the obsolescence of our systems.
Event 4. Vulnerability Solution – State Update in our CI/CD environment
In the worst scenario, we will not be able to patch our systems to correct the vulnerability. Still we have other security options and as such; we must determine and verify the extent of the threat over our systems. So:
- If our system is vulnerable, we can apply alternative security measures to prevent ourselves from the exploitation of the vulnerability.
- If our system is not vulnerable because it affects a specific system that does not compromise the integrity of our entire network infrastructure.
In all cases, it is smart and recommendable to track the new vulnerability by including it in our knowledge base so to process its management; and the updating of our security systems.
Therefore, the management of vulnerability management in our CI/CD environments will always depend on the maturity of our information security system.
As we can see, addressing and managing vulnerabilities in our CI/CD environments is as simple as logical. However, its implications and final management always entails details that represent critical points for the overall health of our digital environments which not always we are able to observe and solve.
In any case, in GB Advisors you have an ally that helps you to solve all the difficulties, and handling vulnerabilities events in your digital environments. Write us here to devise your vulnerability management plan, and keep pace with the latest techniques to mitigate the risk in your systems and environments.
