entity_relationships.md

Entities of Heureka

Full Entity Relationship Diagram

erDiagram
    Issue                   ||--o{ IssueMatch: "may have"
    Issue                   ||--|{ IssueVariant: "has variants called"
    ComponentInstance       }o--|| ComponentVersion: "is an instance of" 
    ComponentVersion        }|--|| Component: "is a version of"
    ComponentInstance       }o--o{ Service: "owned by"
    IssueMatch              }o--|| ComponentInstance: "is a match for"
    ComponentVersion        }|--|{ Issue: "may is associated with"
    IssueVariant            }o--|| IssueRepository: "is an entry in"
    IssueRepository         |o--o| Service: "may belong to a" 
    Service                 }o--|{ User: "has owners"
    Service                 }o--o{ SupportGroup: "has responsible"
    SupportGroup            }o--o{ User: "consists out of"
    Remediation             ||--|| Issue: "Tracks remediation for Issue"
    Remediation             ||--o| Component: "Tracks remediation for Component in Service"
    Remediation             ||--|| Service: "Tracks remediation in Service"
    Remediation             ||--|| User: "Remediated by"
    Patch                   ||--|| ComponentVersion: "Tracks patch of ComponentVersion in Service"
    Patch                   ||--|| Service: "Tracks patch in Service"
    User                    ||--o{ AuditLogEvent: "changes by user to any objects are tracked through"

Loading

The Remediation

erDiagram
    Remediation             ||--|| Issue: "Tracks remediation for Issue"
    Remediation             ||--o| Component: "Tracks remediation for Component in Service"
    Remediation             ||--|| Service: "Tracks remediation in Service"
    Remediation             ||--|| User: "Remediated by"

Loading

The Remediation entity is responsible for documenting remediation actions performed by users. A remediation can be applied to the whole service, meaning it affects all components used in the service, or it can be applied to a specific component within a service. Each remediation is associated with a single issue. The available remediation actions include:

• Mark a finding as False Positive: Identify a finding as incorrect or not applicable.
• Accept Risk of finding: Acknowledge and accept the risk associated with a finding.
• Mitigate finding: Implement measures to reduce the impact or likelihood of a finding.
• Adjust score of finding: Lower the severity or priority score of a finding.

The Patch

erDiagram
    Patch                   ||--|| ComponentVersion: "Tracks patch of ComponentVersion in Service"
    Patch                   ||--|| Service: "Tracks patch in Service"

Loading

The Patch entity is designed to track the patching of assets. When a scanner reports an inventory, such as running containers, this inventory is compared with previously reported data. If a specific ComponentVersion (e.g., a container image) is no longer running, a patch is created to reflect this change. Patches are automatically generated by Heureka through the AutoPatch feature.

The IssueMatch

erDiagram
    Issue                   ||--o{ IssueMatch: "may have"
    IssueMatch              }o--|| ComponentInstance: "is a match for"
    Evidence                |o--o{ IssueMatch: "Mitigates"

Loading

An Issue basically is an equivalent entry of a CVE. It’s the absolute base unit describing a weakness or vulnerability.

An IssueMatch does connect this base unit with the actual component/resource (called ComponentInstance) on which the respective Issue got identified.

An IssueMatch is therefore the actual Issue that we want to fix/patch, as they are an instance of the baseUnit "Issue" deployed in the wilds, and therefore exposing a weakness/vulnerability.

Usually, an IssueMatch is created by a "Scanner" which is related to a "technical User" within the System, but a IssueMatch can also get created by a human for cases where a certain weakness/vulnerability and its patch management process needs to be tracked without having any scanners/tools that are able to automatically detect them.

The IssueVariant & IssueRepository

erDiagram
    Issue                   ||--|{ IssueVariant: "has variants called"
    IssueVariant            }o--|| IssueRepository: "is an entry in"
    IssueRepository         }o--o| Service: "may belong to a"

Loading

The BaseUnit Issue itself does not hold information about its severity, this is set by a so-called IssueVariant which is published by an IssueRepository.

The Issue Repositories have different priority weights and the lowest unit is the default issue variant, in our case the NVD of NIST / CVE of Mitre.

IssueVariants are created by the individual scanners that search for new issue variants in the respective repositories. An exception to this is the IssueVariants created for IssueRepositories that are connected to a service.

These IssueRepositories are custom Repositories that are created to adjust the severity of certain vulnerabilities/weaknesses or to create an issue variant for a not officially (through the other repositories) tracked issue.

The Service

erDiagram
    IssueRepository         |o--o| Service: "may belong to a" 
    ComponentInstance       }o--o{ Service: "owned by"
    Service                 }o--|{ User: "has owners"
    Service                 }o--o{ SupportGroup: "has responsible"
    SupportGroup            }o--o{ User: "consists out of"
    Activity                }o--|| Service: "of a"

Loading

The Service is the central unit used by operational teams as these are the core units for which owners and support groups are assigned. They play a central role and are connected through theire relationships with all of the above described cases/relations.