Security in Devops?

5-minute read

Security and DevOps might be two independent ideas. However, in an agile environment, it becomes important to implement both together. This can be achieved only by maintaining a balance between them in the DevSecOps lifecycle. However, this can get strenuous due to different issues faced by different security teams.

The issues are:

  1. Unclear Understanding about the product environment
  2. Build Version which is in use
  3. Project Stakeholders information
  4. Information about 3rd party components used and their build versions
  5. Missing Documentation about the project/product
  6. Availability of test environments for testing
  7. Eliminating false positives from the results of automated tools
    1. Unclear Understanding about the product environment: The first and foremost issue which exists is that there is no clear information maintained about the environmental category under which the project falls. This means that the project can either be already deployed thus existing in the production environment, or the project might still be under the development phase or for all we know, it might have been depreciated only. Before beginning to test any product, this information is very valuable as it will correspond to their respective test cases. In a production environment, it is quite easy to figure out which products are in production just by hovering to your company’s product portfolio. However, the question is what about those tiny little microservices and Kafka components you are using to achieve the data flow between your products? How do we know which of those microservices are used in the production environment and which are not?For the projects which are still in the Development phase, the issue is that there is no clear information about when the project is going to be released and what will be the use cases for the same.As far as the depreciated ones are concerned, most of the time the situation is, after trying to pentest, code review and perform automated scans for these projects the end news is that the project has been depreciated and is not in use anymore.
    2. Build Version which is in use: The next issue is about the build versions and their release information. This is one of the issues which teams face usually when they are working in an agile environment. In an environment where you have multiple builds of multiple products rolling out every other day, it becomes a tiring job to keep a track of each build and their release dates in order to ensure that no build is released without performing security testing.
    3. Project Stakeholders information: This issue is mostly faced when working in a multi-tier company where each project is usually owned by 1-2 people. Sometimes it becomes a tough job to identify the rightful owner of a project. Fortunately, tools like Jira comes handy while trying to deal with it but in situations when a stakeholder has resigned or have disowned the project, it becomes more difficult to tackle this issue.
    4. Information about 3rd party components used and their build versions: Living in the Open Source world, this issue is imminent by default. Usually, this issue arises while performing Software Composition Analysis, to look for the usage of 3rd party components. There are a lot of them and almost all of them are open source, which makes them vulnerable. However, due to the increased awareness of the security bugs that exists within them, most of these components are well maintained by fixing the various security issues in order to keep these components as secure as possible. Irrespective of that, from a security point of view, it is essential yet challenging to keep a track of these components used along with their build versions. To state this in an example, while using dependency-check to perform Software Composition Analysis it reports vulnerabilities on the components which are being downloaded by maven. Sometimes, it so happens that some of the components are totally unnecessary for usage but it still gets downloaded as it is bundled into the complete package that is required.
    5. Missing Documentation about the project/product: This is a common issue which is not limited to only the security guys, but for everyone who is working with a multi-tier company. Most of the times, there are situations where a new product is launched but the documentation which includes the product details such as the workflow, use cases and the dependencies used are missing.
    6. Availability of test environments for testing: This is a common issue which almost every security team faces is the availability of test environments for testing. Even after setting up a security testing environment, issues such as the testing environment not being updated with the latest build which is on the production or not having all the products and the services enabled on it might arise.
    7. Eliminating false positives from the results of automated tools: As they say, no tool is perfect; every tool is bound to give false positive results. When it comes to large projects it is a tedious and a tiring job to understand every code and dependency used. As a savior, there exist numerous automated scanners that will do this job according to the required specifications and prepare a detailed report of the same. However, these reports are nothing but the scanned results of the rules specified. Thus, there is a possibility of many alerts pointing out to insecure practice which might not actually be the case. This becomes a responsibility of manually verifying these false positive results and ensuring that they are safe to be ignored.

So, these were some issues faced in the initial phase of DevSecOps. Slowly and steadily there will be an adequate bunch of solutions to tackle these issues. Feel free to share your views and opinions with me, my DM is open.