What is to come?
Implementing the analyzer in such a way that the vulnerabilities are stably fixed is not a quick matter. From experience, we can say that it takes from a couple of weeks to several months. If you are implementing the analyzer in a large company, get ready for a series of approvals. After all, these are hundreds of code bases that need to be analyzed, and dozens of teams with their own development orders.
To add a new stage of development - static analysis, you will have to study how the process of each team works and propose a solution that is convenient for everyone. In small companies, the established development order may not exist at all. The implementation of the analyzer can be an excuse for building a process. In order for integration to be softer, we advise you to find out which analyzer has the capabilities for this.
What are the integration options?
Typically, the analyzer assumes a non-graphical interface (CLI, REST) for integration into any process. There are analyzers with ready-made integrations: with build tools and development environments, with version control systems (Git, SVN), CI / CD servers (Jenkins, TeamCity, TFS), project management systems (Jira) and user management (Active Directory). The more useful for your company, the easier it will be to set everything up.
How can you build a process?
Consider the standard situation: the departments involved are information security, release management and development. As a rule, the customer of analyzer implementation is information security (IS). The task is to agree on who, when and what will do. We distinguish the following steps: start the analysis, process the results of the analysis, create a request for fixing the vulnerability, fix the vulnerability, check the fix . Let's consider each step in more detail.
Step 1. Run the analysis
You can run the analysis manually or automatically. Approaches have their pros and cons.
Manually
He himself remembered the analyzer, he downloaded the code, he went and looked at the results.
If there are about a dozen projects in the company and one security officer is entrusted with monitoring security, such a scenario is possible. If there are about a hundred projects, you need to configure automation.
Automated
Decide how often and at what point you need to analyze the code. For example, before entering a productive environment, according to a given schedule (once a week) or after each change.
If the application is rarely updated, but its safety also needs to be monitored, configure the analysis if there are changes.
If a lot of people work on the code, many branches are created, changes often pour in - it is better to analyze often, but do not interfere with development. For example, at the time of creating a merge request with the main branch or when changing the status of a task on this branch. Integration with a version control system or with a project management system will help you with this. Integration with CI / CD will make analysis one of the build steps.
Set the schedule so that you have time to process the results.
Step 2. Process the analysis results
Do not instruct the developers to immediately fix all the vulnerabilities found. Let the security officer verify them first. The results of the first analysis may seem deplorable: dozens of critical, hundreds of less critical vulnerabilities and thousands of false positives. What to do here? We recommend fixing the vulnerabilities gradually. The ultimate goal is to achieve the absence of vulnerabilities in both the old code and the new one. At the initial stage, to verify critical (still unsafe with them) and new vulnerabilities (new code is easier to fix).
Use filters. Sort vulnerabilities by severity, by language, file and directory. More advanced tools will show you vulnerabilities only in the new code, hide vulnerabilities in third-party libraries. Filters have been applied, but are there still many vulnerabilities?
View the most likely vulnerabilities. There are analyzers that evaluate the likelihood of a false positive. If there are many vulnerabilities, and the criticality level is almost the same for everyone, filter the results using this metric. So you quickly process the most likely vulnerabilities (see screenshot below).
Use verification statuses. To capture the results of verification, usually analyzers offer to work with statuses for the vulnerability: confirm or reject as a false positive. As a rule, the work done should be preserved during rescan.
Step 3. Create a request for fixing the vulnerability
If the developer himself launches the analysis of his code and immediately fixes the vulnerabilities, then of course you do not need to create unnecessary requests.
If the security officer reviews and verifies the results, then for the further correction of the confirmed vulnerabilities, a task usually needs to be set. We have repeatedly faced the fact that it was at this step that difficulties arose.
Request form
There are companies in which large tasks for the stage are fixed in the project management system (for example, Jira). And for subtasks and bugs, for example, GitLab Issues are used, access to which only the team leader and his team have. It also happens that the assembly is impossible without creating a separate task in the project management system. The analyzer can have integrations with which you can create the necessary queries right away in the interface.
Often within the same company with numerous development groups, each of them has its own procedure for implementing work tasks. And you need to adapt to everyone. There are questions:
- Is it worth it to allocate a separate project for fixing vulnerabilities or create tasks in existing ones?
- Is vulnerability a familiar bug or a new entity?
- Create a separate task for each vulnerability or group similar ones?
- What should I give as a description of the problem: a link to a vulnerability in the analyzer interface or a place in the code and briefly describe the problem?
- And does the developer need access to the results - just send a PDF report with the text “see page 257 ”and that's enough?
Of course, it depends on how the process in the team is adjusted, what error tracking systems are used.
If the code is written by contractors for whom access to internal systems is minimal, a scheme with a PDF report is suitable. Typically, for a report, you can select vulnerabilities that are of interest to you and immediately send them to the desired address from the analyzer interface.
If in the company not a single step is possible without creating a project for a certain type of tasks with a certain amount of resources, then you should look for a tool with integration for your system. The most flexible integrations will generate a description of the task for you (they will not even forget about the link to the source code in the version control system) and will allow you to fill in all the required fields. Choose the type of task, specify the parent, artists and even the release version.
Labor costs and terms
If the team decided to give an assessment of the labor costs for each task, then the task of fixing the vulnerability needs to be done the same. Along the way, developers verify the vulnerabilities. Sometimes at this step it turns out that the vulnerability is false or impossible to exploit.
But as a rule, resources are still not enough to immediately fix all vulnerabilities. Therefore, it is also necessary to coordinate their priorities.
The tasks were determined by labor costs and priorities - then those responsible for the release dates (this may be the project manager or the same team lead) decide what to fix and when. At first, using the analyzer, we advise you not to postpone the release, if not all vulnerabilities are fixed.
Step 4. Fix the vulnerabilities
How to properly allocate resources: connecting new people or entrusting to those who are already engaged in development is a budget issue. One thing is true: if the company allocates resources for the installation of the analyzer, you need to prepare for the costs of fixing vulnerabilities. A possible way is to lay the percentage of time to fix vulnerabilities as a job with technical debt.
There are two scenarios: correct immediately in the development process or at the request of a security officer. Fixing vulnerabilities during development is an ideal scenario. Immediately found - immediately corrected. The developer scans his feature branch before requesting a merge with the main branch. This can also be automated through integrations: with the development environment, with build tools, version control system, or with CI / CD.
Another scenario is to analyze the main development branch after all the changes. A security officer or team leader reviews the results and creates tasks to fix vulnerabilities. This scenario is more time consuming. At the developer’s input is the source code, the correction task, and the analysis results. For a developer, the task of fixing a vulnerability is not much different from fixing a bug.
Step 5. Verify the fix
You need to make sure that the vulnerability is really fixed and a new one has not appeared in its place. There are results of the analysis of the corrected code. What to search? File and line number of the vulnerability? Or search by vulnerability name? Could be so. But if the code was changed, the line with the vulnerability could shift, and there could still be many occurrences of one vulnerability. Some analyzers may show "fixed" vulnerabilities. Agree, so you can check the vulnerability fix faster (see screenshot).
Examples
Here are two possible scenarios.
Scenario 1
The team uses Git for version control, Jira for project and task management. Jenkins configures the build schedule. For example, once a day if there are changes in the branch. As an additional step, the start of the analyzer is indicated.
The security officer reviews the results of the analysis of the main branch (master or development), the developers - his feature branches.
Developers fix vulnerabilities if necessary. If the analyzer can filter vulnerabilities on demand: show only new vulnerabilities or not show vulnerabilities in third-party libraries, show vulnerabilities in a specific directory or file - the developer will be able to quickly view the results that interest him. So, the probability of correction is higher.
The security officer reviews the results of the analysis of the main branch. Through integration with Jira, the security officer creates vulnerability management tasks from the analyzer interface. Next is the coordination of deadlines and priorities.
When the vulnerability is fixed and the new code passes all the internal development stages (review from team lead, user and regression testing), the security officer must make sure that the vulnerability is no longer there. The author closes the completed task.
Scenario 2
The code for the company is written by a group of contractors. Timlid interacts with developers via email and uses GitLab for version control. Contractors do not have access to internal project management systems (Jira).
The security officer or the team leader himself reviews the results of the analysis of the main development branch. Contractors do not have access to the analyzer. If there are vulnerabilities that need to be fixed, the security officer sends a PDF report with the results of the analysis to the team leader or immediately to the developer.
From the report, the developer finds out where the vulnerability is found, what it consists of and how it can be fixed. It is valuable if for vulnerabilities related to the flow of insecure data (for example, SQL injection), the distribution scheme will be unloaded into the report: from the data source to their use in the function / method call (see screenshot).
After fixing the vulnerability, the team leader informs the security officer that it is time to check the results of the re-scan.
What else is important?
To establish the interaction between information security and development. It is important that both parties are interested in fixing vulnerabilities. Well, if it will be not only requests, but also live communication.
Do not neglect user roles. A good analyzer should have the ability to differentiate rights. It is unlikely that a contractor will need administrator rights or the results of an analysis of internal systems. To edit the results - to change the criticality and status - it is enough to allow the security officer and team lead. The principle of minimum privileges has not been canceled.
If the company is large and uses a user management system (for example, Active Directory), consider tools with ready-made integration. You will be able to reuse the roles and groups accepted in the company and give them the necessary rights.
Output
After choosing an analyzer, prepare for the fact that it still needs to be correctly implemented. Do not be afraid of meetings and approvals with participants: the better you understand in the process, the more useful the result. It is important that the work scenario is not only approved, but also started to follow.
Posted by Elizaveta Kharlamova, lead analyst, Solar appScreener