16. Vulnerability Scanning Policy

Luma is proactive about information security and understands that vulnerabilities need to be monitored on an ongoing basis.

Luma utilizes GitHub security, Snyk, Trivy, Rapid7 DAST, Intruder, AWS Inspector, and Hamming AI to consistently scan, identify, and address vulnerabilities on our systems, including vulnerabilities in Luma’s AI functionality (scanned via Hamming AI).

16.1 Applicable Standards

16.1.1 Applicable Standards from the HITRUST Common Security Framework

• 10.m - Control of Technical Vulnerabilities

16.1.2 Applicable Standards from the HIPAA Security Rule

• 164.308(a)(8) - Evaluation

16.2 Vulnerability Scanning Policy

1. GitHub security and Snyk are used to identify vulnerabilities in application dependencies and source code (SAST/SCA). Management of these tools is performed by the Luma Security Officer, or an authorized delegate of the Security Officer.
2. Frequency of dependency and source code scanning is as follows:
   • on a daily basis for the existing codebase
   • on every pull request for new code
3. Container images are scanned for OS-level vulnerabilities using Trivy or AWS Inspector, depending on the product.
4. Frequency of container image scanning is as follows:
   • on a daily basis for existing images
   • on every pull request for new code
5. Rapid7 is used to perform dynamic application security testing (DAST) against Luma’s web applications.
6. Frequency of DAST scanning is as follows:
   • for each major and minor release
7. Intruder is used to monitor Luma’s AWS configuration, external-facing IP addresses, and exposed entry points for vulnerabilities.
8. Frequency of external scanning is as follows:
   • on a quarterly basis
   • when a new emerging threat is identified
   • when a new external endpoint is introduced
9. AWS Inspector is also used to continuously monitor Luma’s internal hosts and infrastructure for vulnerabilities.
10. Frequency of internal scan review is as follows:
    • no less than quarterly
    • when a new emerging threat is identified
11. Hamming AI is used to scan Luma’s AI voice/audio agent for vulnerabilities, including AI-specific security threats.
12. Frequency of AI voice/audio agent scanning is as follows:
    • every Friday
13. Reviewing GitHub, Snyk, Trivy, Rapid7, Intruder, AWS Inspector, HackerGuardian, and Hamming AI reports and findings, as well as any further investigation into discovered vulnerabilities, are the responsibility of the Luma Security Officer or a delegate. The process for reviewing the reports is outlined below:
    1. The Security Officer initiates the review of a report by creating an Issue in ClickUp. If deemed appropriate, the Security Officer may choose to address the issue without creating a ticket with the aid of a delegate.
    2. The Security Officer, or a Luma Security Engineer assigned by the Security Officer, is assigned to review the report.
    3. If new vulnerabilities are found during review, the process outlined below is used to test those vulnerabilities. Once those steps are completed, the Issue is then reviewed again.
    4. Once the review is completed, the Security Officer approves or rejects the Issue. If the Issue is rejected, it goes back for further review.
    5. If the review is approved, the Security Officer then marks the Issue as Done, adding any pertinent notes required.
14. In the case of new vulnerabilities, the following steps are taken:
    • All new vulnerabilities are verified manually to assure they are repeatable. Those not found to be repeatable are manually tested after the next vulnerability scan, regardless of if the specific vulnerability is discovered again.
    • Vulnerabilities that are repeatable manually are documented in the Risk Register and reviewed by the Security Officer and Privacy Officer to see if they are part of the current risk assessment performed by Luma.
      • Those that are a part of the current risk assessment are checked for mitigations.
      • Those that are not part of the current risk assessment trigger a new risk assessment, and this process is outlined in detail in §4.3.1.
15. All vulnerability scanning reports are retained for 6 years by Luma. Vulnerability report review is monitored on a quarterly basis using ClickUp reporting to assess compliance with above policy.
16. This vulnerability policy is reviewed on an annual basis by the Security Officer and Privacy Officer.
17. Luma receives weekly intelligence reports on emerging new threats, and infrastructure is automatically scanned for new threats as they are identified to assess whether we are vulnerable.
18. External Vulnerability Scanning is also performed:
    • Scans are performed by HackerGuardian, a PCI SSC Approved Scanning Vendor (ASV)
    • Scans are performed no less than quarterly, and/or following any material change to the production environment
    • Scans and any rescans performed shall satisfy the ASV Program Guide Requirements
    • Should any scan fail ASV Program Guide Requirements, remediation will be performed in accordance with Luma Health policy detailed above, and appropriate rescans shall be performed

16.3 Penetration Testing

Luma engages a qualified third-party to perform an application penetration and vulnerability test. This takes place no less than annually, and after any significant infrastructure or segmentation changes. The scope of this testing includes Luma’s AI functionality (e.g., AI red teaming). Any findings will be handled following this policy.

The penetration test methodology includes but is not limited to:

• Based on industry-accepted approaches such as NIST SP800-115;
• Coverage for all critical systems;
• Testing from both inside and outside the network;
• Review and consideration of threats and vulnerabilities experienced in the last 12 months;
• Retention of results and remediation activity results;
• Repeated testing following remediation of exploitable vulnerabilities to verify corrections;
• Testing of all segmentation methods, to confirm they are operational and effective, and isolate all out-of-scope systems from systems in the CDE;
• Coverage for all segmentation controls and methods;
• Coverage for AI-specific security threats, such as data poisoning and model inversion;
• Defines application-layer penetration tests to include common coding vulnerabilities
• Defines network-layer penetration tests to include components that support network functions as well as operating systems