FAQs: Vulnerability management: scanning, remediation, and evidence

This article brings together common customer questions and practical answers based on typical Secureframe workflows, compliance situations and unique tech stacks.

It is meant as quick reference material for day-to-day use of the product.

Patching and remediation

What should a company do if they discover missed vulnerability remediation SLAs during an audit?

  • The company should immediately begin remediating outstanding vulnerabilities and document corrective actions, such as improving tracking processes, strengthening monitoring, or enhancing escalation procedures. Demonstrating that the issue has been identified, resolved, and prevented from recurring can help reduce audit risk and show strong control maturity.

Penetration testing

Can a penetration test be conducted internally?

  • Yes, that's fine.

How often should external penetration testing be performed?

  • External penetration testing should be performed at least once every 12 months.

Is a penetration test needed for GDPR?

  • A penetration test is not a hard requirement for GDPR but vulnerability management is. A penetration test would satisfy vulnerability scanning requirements if one is in place.

Is organizational independence of the penetration tester required?

  • Yes, organizational independence of the tester is required, but the tester is not required to be a QSA or ASV.

Until when is the multi-tenant service provider penetration testing requirement a best practice?

  • This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.

What are the baseline requirements needed for a PenTest?

  • The application should be in scope, and it's recommended to include the network (IP addresses). However, there are no hard requirements, as penetration testing is not mandatory.

What are the options for multi-tenant service providers to meet the penetration testing requirement?

  • multi-tenant service provider may either provide evidence to its customers to show that penetration testing has been performed according to Requirements 11.4.3 and 11.4.4 on the customers’ subscribed infrastructure, or provide prompt access to each of its customers so customers can perform their own penetration testing.

What does remediating vulnerabilities found by a penetration test do?

  • Remediating vulnerabilities found by a penetration test significantly reduces the probability that the same vulnerabilities will be exploited by a malicious attacker.

What else should penetration tests confirm regarding segmentation?

  • Penetration tests should confirm effectiveness of any use of isolation to separate systems with differing security levels (see Requirement 2.2.3).

What happens if there's findings in a PenTest?

  • There's no penalties for finding vulnerabilities on a pen test, but it's important to start working on the vulnerability management process for remediation of future findings. Remediation in a timely manner is what auditors care about, not necessarily the actual findings (if any).

What is a penetration test?

  • A penetration test is a manual test, with automated tool support, where experts attempt to identify and exploit vulnerabilities in mobile/web applications or internal networks. These tests are typically conducted on publicly-exposed endpoints, but advanced frameworks may require testing within the internal network.

What is the difference between vulnerability assessments and penetration tests?

  • Vulnerability assessments scan a network for vulnerabilities, while a penetration test actively exploits those vulnerabilities. A vulnerability scan is typically done via open-source tools or internal tools, while a penetration test is done by an independent pen tester and may include techniques like social engineering and open web vector testing.

What is the purpose of penetration testing?

  • The purpose of penetration testing is to provide a prioritized list of vulnerabilities discovered.

What must multi-tenant service providers do regarding penetration testing?

  • Multi-tenant service providers must support their customers for external penetration testing per Requirement 11.4.3 and 11.4.4.

What should be considered when choosing a qualified resource to perform penetration testing?

  • Specific penetration testing certifications and prior experience conducting penetration testing should be considered when choosing a qualified resource to perform penetration testing.

When else should external penetration testing be performed?

  • External penetration testing should be performed after any significant infrastructure or application upgrade or change.

When should I do a Penetration test (Pen test)?

  • Pen tests should be done at least annually by a third-party vendor. This meets SOC 2 audit requirements if you track critical and high-risk vulnerabilities through remediation. Penetration tests are a security best practice, even if the requirement varies by auditor or SOC 2 type.

Where can I find additional guidance on penetration testing?

  • Refer to the Information Supplement: Penetration Testing Guidance on the PCI SSC website for additional guidance.

Who should perform external penetration testing?

  • External penetration testing should be performed by a qualified internal resource or qualified external third party.

Will a pentest run-through Inspector be sufficient for pen testing?

  • No, a penetration test requires more than a simple run-through of tools like Inspector. Penetration tests are performed by security experts who actively exploit vulnerabilities, not just identify them.

Would a vulnerability assessment be covered in a penetration test?

  • A vulnerability assessment and penetration test are related but different. A vulnerability assessment typically scans for vulnerabilities, while a penetration test exploits them. Often, a vulnerability scan is performed first, followed by a penetration test. For SOC 2, a penetration test usually focuses on web applications, and third-party firms are recommended for these tests.

Scanning and findings

Does Secureframe monitor for encryption-specific CVEs, including post-quantum or legacy encryption vulnerabilities?

  • Secureframe will surface encryption-related CVEs if they are flagged by a connected scanner, but does not currently have independent monitoring or alerting specifically for encryption vulnerability categories (e.g., post-quantum encryption or deprecated standards like 512-bit).

Does Secureframe query independent CVE databases like NVD or CVE.org?

  • Not currently. Secureframe aggregates vulnerability data from connected scanners but does not independently query external CVE feeds. If coverage from sources like NVD, CVE.org, OSV, or the GitHub Advisory Database is needed outside of a connected scanner, that would require a product enhancement.

Does Secureframe support Cisco severity ratings for CVEs?

  • No. Secureframe uses standard CVSS-based severity tiers (Critical, High, Medium, Low) and does not currently support Cisco-specific severity frameworks as an alternative classification.

How can I integrate a non-production AWS account while keeping cloud assets out of scope for vulnerability scans, especially when vulnerabilities are still showing up despite scans being disabled for certain AWS accounts?

  • Currently, Secureframe does not support selectively excluding assets from only vulnerability scans while keeping them included in other tests. If you integrate a non-prod AWS account, its assets will be pulled into your environment and included in all applicable tests unless you explicitly mark them out of scope.

    You can bulk mark assets out of scope by:

    Increasing the asset display count to 100 per page

    Selecting multiple resources at once

    Using the “Out of Scope” option that appears at the bottom of the page (Support Guide)

    However, note that marking assets out of scope excludes them from all tests, not just vulnerability scans.

    Because of this limitation, many customers choose to not integrate non-production AWS accounts or disconnect them entirely if fine-grained test exclusions aren’t possible.

How do we handle external vulnerability scanning?

  • If they are hosting a web application, I would recommend vulnerability scanning tools such as Acunetix or a free tool like OWASP Zap.

How is internal vulnerability scanning different than external vulnerability scanning?

  • Internal scans are done by inherent services (e.g., AWS Inspector or GitHub Dependabot), while external scans are done by open-source tools or third-party providers.

We have an integration with Jira that reports on tickets tagged as SECURITY_VULNERABILITIES with a 5-day SLA. We logged a vulnerability as soon as it was detected by our scanning tool, but Ubuntu has not released a patch yet. It has been 10 days, so Secureframe is flagging it as failing. We cannot fix it until Ubuntu releases the patch. What should we do?

  • If the organization believes a 5-day SLA is critical, you should not change the SLA just to accommodate this case. However, in practice, critical and high vulnerabilities are commonly remediated within a 30-day remediation window.

    Best practice is to:

    Keep monitoring the issue in Jira.

    Document updates in the ticket (e.g., notes about Ubuntu’s patch release status, communications, or tracking links).

    If an auditor asks, you can demonstrate that you have been actively monitoring and managing the risk, even though remediation isn’t possible yet.

    This way, the SLA policy remains intact, and you have evidence showing due diligence.

What is the AWS vulnerability scanning feature? Does GuardDuty work?

  • AWS Inspector is the internal vulnerability scanning service. GuardDuty does threat detection, but it does not suffice for internal vulnerability scanning. For virtual machines, AWS Inspector should be enabled. For containers, use AWS Elastic Container Registry (ECR).

What is the bare minimum frequency for vulnerability scanning?

  • Vulnerability assessments should be performed at least annually, though more frequent scans (quarterly or monthly) are recommended based on the policy, framework, and components being scanned.

What vulnerability scanning tool(s) should customers use?

  • For web application scanning, we recommend tools like SonarCloud, Snyk, Acunetix, Burp Suite, and ZAP Proxy. The frequency of scans depends on your security needs. For open-source tools, consider GitHub's CodeQL or GitLab’s built-in security features.

What's recommended for internal vulnerability scanning?

  • Using CSPs' inherent vulnerability scanning tools such as AWS Inspector and GCP security scanning.

Where does Secureframe pull CVE data from on the Vulnerability page?

  • Secureframe sources CVE data directly from your connected security scanning tools (e.g., Tenable, Qualys, Wiz, AWS Inspector) rather than from an independent feed like NVD, CVE.org, OSV, or the GitHub Advisory Database. The comprehensiveness of your vulnerability data depends on which scanners you have integrated.

Will Azure Defender suffice for internal vulnerability scanning?

  • Yes, Azure Defender can suffice for internal vulnerability scanning. It provides a comprehensive security solution and is suitable for this purpose.

Vulnerability management

A vulnerability management program is designed to give you insight into your infrastructure and systems. What best describes your vulnerability management program?

  • We conduct regular vulnerability scans of our production infrastructure, triage results, and have a defined period for fixing identified vulnerabilities.

How do organizations handle vulnerability management without Secureframe?

  • They conduct vulnerability scans using separate tools, manually track vulnerabilities in spreadsheets, and coordinate remediation efforts through meetings and emails.

How does Secureframe enhance vulnerability management?

  • Secureframe integrates with tools like AWS, Azure, GCP, and GitHub to track vulnerabilities in real-time, automatically update remediation status, and provide a centralized dashboard for monitoring vulnerabilities.

How does Secureframe support vulnerability management?

  • Secureframe integrates with security tools to track vulnerabilities, monitor remediation, and automate reporting.

Is it possible to import repositories, vulnerability data or tickets through the custom data platform?

  • No, not at this time.

We do not currently have SLAs in place for fixing vulnerability & threat tracking and resolution. Do we need those?

  • For critical and high vulnerabilities, you do need SLAs, but stretch the days to what is manageable for you without going too far out. This should also be defined in your policy, if not already.

We have two SLA entries using the same label (Vulnerability_threat_tracking) for different Jira priorities (Critical = 15 days, High = 30 days). Why is SLA evaluation behaving unpredictably?

  • Secureframe evaluates SLA compliance based on label only, not Jira priority. When two SLA entries share the same label, evaluation results are unpredictable depending on which entry is processed first. The fix is to use unique labels per SLA entry (e.g., Vulnerability_threat_tracking_critical and Vulnerability_threat_tracking_high), then update the corresponding Jira tickets to match. For large ticket volumes, use Jira's bulk edit feature to update labels by priority group. Once labels are aligned in both Secureframe and Jira, SLA evaluation will work correctly.

What is vulnerability management?

  • It is the process of identifying, tracking, and mitigating security vulnerabilities to maintain compliance and protect sensitive data.

Additional customer questions

Do all vulnerabilities need to be resolved?

  • While vulnerabilities do not need to be resolved immediately, they must be tracked and acknowledged. Remediation plans should be in place to address vulnerabilities within the required timeframe: 90 days for low-risk, 60 days for medium-risk, and 30 days for high/critical risks.

Does Secureframe provide instructions for resolving vulnerabilities?

Secureframe does not provide step-by-step vulnerability resolution instructions in-app. Each vulnerability is linked to its corresponding CVE entry, which includes details and remediation guidance. You can also use your cloud service provider’s (CSP’s) native security tools (such as AWS Inspector) or vulnerability scanners to identify and remediate issues.

How is the “In Audit Scope” column updated in the Vulnerabilities page?

For vulnerabilities pulled in through third-party scanning tools (not AWS, Azure, or GCP), they are automatically marked as in scope because they are not directly tied to resources in the Secureframe asset inventory.

Currently, these vulnerabilities are included by default, but the ability to manually ignore them will be available with upcoming platform updates.

How would you recommend replying to a customer asking how we handle vulnerabilities?

We track vulnerabilities detected by native vulnerability scanners, such as AWS Inspector, and aggregate them in Secureframe’s vulnerability management module. This helps us manage and mitigate detected vulnerabilities efficiently.

Why do vulns show as "Closed" on the dash, what does "Closed" mean?

  • The dashboard displays vulnerabilities as "Closed" because it retrieves this status directly from the integrated AWS data. A "Closed" vulnerability is considered resolved. These vulnerabilities are retained for audit and historical tracking purposes, but they no longer represent active risks.

Related to

Was this article helpful?

Have more questions? Submit a request

Comments

0 comments

Please sign in to leave a comment.