This article details the Information Assurance guidelines for self-managed LILT installations

​
Purpose

LILT shall perform a static vulnerability analysis of all Docker images provided to Customer before delivery. The purpose is to keep known common vulnerabilities and exposures (CVEs) from deployment on secure systems.

​
Analysis

LILT uses Grype, an open source project by Anchore, and a comprehensive vulnerability/misconfiguration scanner for containers and other artifacts.

​
Vulnerability Levels

  1. LILT shall attempt to resolve all CRITICAL, HIGH, MEDIUM, and LOW CVEs with known fixes in advance of any deliverable.
  2. LILT will track any CRITICAL, HIGH, MEDIUM, and LOW that have no known fixes and resolve them in advance of the next deliverable after fixes are reported or other alternatives are found to mitigate the CVE issue while also keeping the LILT application operational.
  3. In instances where vulnerabilities cannot be resolved because they would impair functionality of the LILT system, such vulnerabilities shall be documented with an explanation.
  4. INFORMATIONAL/NEGLIGABLE CVEs shall not be regularly resolved.
  5. LILT resolves CRITICAL and HIGH CVEs within its images as part of continuous CVE evaluation and hardening. The LILT target for CVE remediation for this severity is 7 days but varies with development effort and available CVE resolutions.
  6. LILT evaluates MEDIUM and LOW CVEs for potential remediation in a future release if requested by a customer.

​
Regular Updates

For the duration of contractual obligations, LILT shall deliver Docker image updates to the Customer’s technical team every twelve weeks. The Customer shall be responsible for system upgrades using these assets.

​
External Dependencies

External dependencies shall be used as-is, but shall also be scanned prior to delivery. LILT shall regularly review external dependencies to best mitigate CVEs.

​
Development Process

In order to ensure release of the safest, highest-quality code, the LILT development follows the below process.

​
Development

A developer from LILT’s technical team assesses the product requirements for a feature. Thereafter, the developer begins software development in a branch off of the main coding branch of the relevant repository. LILT has multiple code repositories, one for each major section of the LILT architecture.

​
Code Review and Unit Testing

Before code is merged back into a main branch, the author of the code opens a pull request on LILT’s Github instance. Unit and integration tests are automatically performed on our CI/CD instance, Jenkins which runs on LILT servers. The results of the tests are then automatically displayed in the pull request with a green check mark indicating tests successfully passed. When tests are passed, LILT’s configuration requires both AI and human review of the code, or an area expert is selected if the code is particularly sensitive. The code is not merged into the main branch until peer reviewers manually approve the request.

​
Release

Self-managed releases happen once quarterly. In this process, all technical teams are required to have code finished and tested per the above process by a particular date (“soft deadline”). Finally, the build is pushed to a staging environment that mimics a self-managed customer’s operating environment, and the technical team and our QA testers manually confirm that all new features work as desired, as well as a standard set of critical platform features.

​
Deployment

For self-managed releases, packages are provided as Docker images in .tar format and ECR via the channel most appropriate to the customer. Typically, images are hosted on a private S3 bucket, but can also be physical media or other solutions.

​
CVE Review

CVEs are automatically reported via our CI/CD tool based on the tools in the section Analysis in this document. Repositories are required to be clean of any LOW and higher CVEs before any release is deployed; additionally, a final check before the release of any deliverable is done to ensure no self-managed packages are deployed with known LOW or higher CVEs at the time of release, though LILT reserves the right to make a discretionary call to release the software with CVEs if testing is complete and the newly discovered CVEs are deemed to have mitigating factors that lower the impact severity. These CVEs will be included in the justification documentation.