My company uses multiple tools for vulnerability scanning. We have Nessus Pro for network scanning, White Source Bolt and GitHub Dependabot for dependencies, and SonarQube for source code, and Burp Suite Pro for web applications.

These make us very complicated when clients or my executives or internal auditors ask us to provide the evidence of how efficient we conduct the vulnerability scanning. The efficiency evidence, not just to provide the Policy & Procedure for paperwork.

Initially, we expect to have the vulnerability reports stored on Google Drive by the respective periodical, folders organized by year-month. For example, network vulnerability reports by month, application vulnerability reports by release. I assume all vulnerabilities were remediated through a defined set of Policy & Procedures with the remediation verification report.

How to manage my vulnerability scan reports efficiently. We are not a business that just says "yes" or "no" when asked about security.

  • 1
    Since it is the auditors that are asking, have you asked them what evidence they will accept?
    – schroeder
    Sep 6 at 6:58
  • I am curious about how to manage these documents efficiently, not how to produce these reports. I am facing various vulnerability report files by product release, monthly, by quarterly. Are there any solutions to efficiently manage them?
    – Toan Ha
    Oct 2 at 8:21

The first step should be to define your process. There are different ways to do this, but in my experience, documents or slide decks are the most common. The description of your vulnerability management process may be part of a larger document or deck or broken down into different documents with their own maintainers, depending on your organizational needs. Regardless of the format, the document would answer questions like:

  • What tools are used for vulnerability scans? What is the output of reports of each tool?
  • How frequently are the tools updated with the latest vulnerability information?
  • Are scans run continuously or at a cadence? If on a cadence, what cadence?
  • For static scans, what code or environments are scanned?
  • For dynamic scans, what environment is targeted? How close is this environment to production? How frequently is it updated?
  • When a vulnerability is identified in a tool, how is it assessed or triaged? If it is determined to be a valid vulnerability in the system, how is it tracked to closure? If it is not a valid vulnerability, how is this documented?

Based on the answers to the question, you'll be able to figure out a lot of the other pieces.

The plan of storing reports in Google Drive with appropriate date organization does seem sufficient, but I'd want to look at ways to automate the process as much as possible. Can the vulnerability scanner store reports internally and you can export them on-demand? Do you trust the tool to do that? Can the vulnerability scanner integrate with defect tracking to record findings for triage? Can the vulnerability scanner be scheduled or triggered to run on certain events? Taking the human out of the loop as much as possible tends to let people focus on the things that people need to focus on rather than executing highly mechanical processes like downloading a report from a tool and uploading it to a repository.

If you're frequently fielding questions or audits from clients, you may want to consider if it makes sense to go after an ISO 27001 or SOC 2 audit. Their scope is much broader, but vulnerability management is a small piece of it. Having a third-party audit assess your process and review your objective evidence in order to get a certification or report that supports it could be something that you can just turn over to clients and reducing the complexity of their audits. They may accept the ISO 27001 certification or the SOC 2 report as sufficient and move on to other topics not covered.

  • I like your "taking human out of the loop" part. I want to improve the important components of How we do compliance, not how to compliance. For example, when we said we do the vulnerability scanning quarterly, technically, we will have to produce a report and escalate issues to the Jira project and make it through the remediation phase. We have the manual progress reports and re-test reports. Can you propose a way/solution to manage this document. How to ensure their confidential and integrity.
    – Toan Ha
    Oct 2 at 8:31
  • @ToanHa Do you need that report to be a document? For example, some vulnerability scanning tools allow you to retain all past scans in the tool. If you can demonstrate that your tool contains those past results, do you need to manage a document? Probably not. Other integrations, such as between the scanner and Jira to log issues, depend on your scanner. My general advice would be to eliminate documents, though, and go with records maintained in various tools. If you need documents, see if you can't script running the scan, downloading the file, and uploading it to a repository. Oct 3 at 21:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.