As you're preparing for an audit you are typically required to provide evidence of vulnerability scans to an auditor (relevant frameworks: ISO 27001, TISAX, SOC 2). On this page, we explain the types of evidence the auditor will require and share best practices.
Required evidence for vulnerability scan
Auditors generally request the following:
Evidence that a vulnerability scan was performed within the past three months
Evidence that a sample of vulnerabilities was remediated within SLA that you defined. Secfix recommends remediating:
high-severity vulnerabilities within 30 days
medium-severity vulnerabilities within 60 days
low-severity within 90 days
Usually, you only need one scan per quarter to demonstrate your compliance.
Uploading Your Evidence
The evidence should be uploaded in the Manual Evidence page, typically by showing:
Findings from a recent Vulnerability scan
Sample tickets that demonstrate the vulnerabilities were tracked and fixed in compliance with your company's SLAs, as specified in your Vulnerability Management policy
Vulnerability scanning methods
You can fulfil the vulnerability scanning requirement in a few different ways. Specific requirements as to which vulnerability scan is best differ from auditor to auditor, so we recommend asking your auditor early on in the audit process. Below you'll find examples of different vulnerability scanning methods.
Penetration testing
Since penetration tests typically involve running vulnerability scans against server host environments and manual validation by experienced vulnerability researchers, these are accepted by most auditors. Usually, it is highly recommended to conduct a pentest at least once a year.
You can submit recent penetration test reports in Manual Evidence.
💸 You can use requestee.co - Pentest Marketplace to get offers from verified pentesters quickly. Secfix has special partner conditions and discounts on pentest. Find out how much a pentest costs.
Container Scanning
You can use container scanning tools to scan for vulnerabilities in your packages and misconfigurations when deploying code via containers.
💡 This is ideal for clients utilizing serverless or PaaS, employing tools such as:
AWS ECR Container Scanning
Google Cloud Repository Container Scanning
Azure Defender for Containers
Snyk
Qualys
💡If you run servers, some auditors require host-based server scanning as a strict requirement. In these cases, you need to do server scanning in addition to container scanning.
Source code and dependency scanning
These tools scan for code and code dependency vulnerabilities. Also known as Static Application Security Testing (SAST) Tools, they help analyze source code or compiled versions of code to help find security flaws. Recommended tools include:
Snyk
Github Dependabot
Qualys
Veracode
You can find more tools in OWASP recommendations.
💡 Similar to container scanning, some auditors may ask to do the server scanning on top.
Server scanning
These tools scan server hosts for package vulnerabilities:
AWS Inspector (for AWS customers)
Azure Defender for Servers (for Azure customers)
Tenable Nessus (for GCP customers)
Threat Stack
Summary
No matter which method you choose, it's essential you:
regularly conduct vulnerability scanning,
have a a process in your ticketing system where you work on fixing the vulnerabilities.
Assistance and Discounts
💬 Get in Touch: Reach out to your Customer Success Manager for expert advice on selecting the most suitable vulnerability scanner.
💸 Partnership Benefits: Enjoy exclusive discounts with our security SaaS partners for the tools you’re considering. Connect with us to bag a great deal!
FAQs
Do I need to run a vulnerability scan if we're a service company and don't have our own own application?
If your company only offers services without having its own application, it's sufficient to conduct an internal network scan. You can use tools like Nessus for this purpose (check out their free trial). The ISO 27001 standard is flexible about what needs to be scanned if there is no digital product involved. An internal network scan, in any proportion, would be acceptable to meet the requirements.
We're a software agency and the code is developed in customer environments. Do we still need to run a vulnerability scan?
In this situation, the responsibility for vulnerability scanning lies with the customer, as the code is developed in their environments and according to their requirements. Conducting such scans might increase the service cost and is ultimately the customer’s responsibility since the product is theirs. However, it is advisable for the software agency to implement tools like SonarQube on some internal development projects. This demonstrates readiness and adherence to best practices for any internal projects.
Is a penetration test mandatory for the 2022 version of ISO 27001?
It is highly recommended but not mandatory. Conducting annual penetration tests is considered a good practice for implementing vulnerability management controls effectively. Secfix recommends remediating:
high-severity vulnerabilities within 30 days
medium-severity vulnerabilities within 60 days
low-severity within 90 days
It's crucial to track the remediation of all critical and high findings through a ticketing system.
What is the required recurrence for vulnerability scanning?
Vulnerability scans should be conducted at least quarterly. For the first audit, ensure that a vulnerability scan has been conducted within the past three months. Additionally, document the remediation tasks for any critical and high vulnerabilities identified during the scan to demonstrate compliance and effective vulnerability management.