Skip to content

cravex2-reachability: Evaluate and implement rule-based tools for triaging vulnerabilities #1961

Description

@pombredanne

The goal is to create an integrated, rule-based system to filter or rerank automatically the vulnerabilities in the context of the managed application, system or device. This will integrate the emerging SSVC scoring for decision tree-driven automation.

Practically this could look like this:

  • Say I have a software product with a bunch of packages, some affected by vulnerabilities
  • Given data about severity, risks, SSVC, and other input, the goal is to re-rank and prioritize the vulnerabilities... some rules could be:
    • If a package is used only in development, then make the priority low or lower. This can be based on the "is_deployed" and "Purpose" fields in a DejaCode product-package.
    • If there is an exploit for a vulnerability, make the priority high
    • If the CVSS is under 5, ignore issue
    • if the CWE is XXXX, then raise/demote/mute/promote priority
    • If SSVC (recomputed in the product context) is ZZZZ, then do YYYY
    • if risk score is above 7, then send notification to XXXX via (slack, email, etc)
    • If EPSS is above XXXX, then promote...

The rules would be eventually be user-configurable, and organized in a groups or profile. For instance, a set of rules could be for CRA compliance (and could be delivered as base set of rules built-in), or you have a set of rules for Mobile apps and another for internal apps or another for Fedramp compliance

Some things to check:

  • research for tools and docs about this, including in FOSS or proprietary solutions
  • Policy as code
  • Rego
  • other rule engine and languages (see drools)
  • policy languages
  • decision tree

Activity

  1. pombredanne commented on Aug 1, 2025

    @pombredanne
    MemberAuthor

    Also this rules system could be evolved in the future for other purposes... for instance:

    • integrate reachability of course
    • deal with license policies in a more fine grained way
    • deal with license compatibility
    • deal with other interesting events such as end-of-life/maintenance/support
    • deal with other criteria such as code quality, projects vitality, dependency tree, etc.
  2. self-assigned this
    on Apr 9, 2026
  3. TG1999 commented on Jun 12, 2026

    @TG1999
    Contributor

    Every rule will be a kind of decision tree, every rule will have results like {action, timeline}

    Points - A - package.risk>1, B - package.vulnerablitiy.cwe=123, C- package.vulnerablitiy.epss>2
    Decisions- Dec1: Do system upgrade, 24 hours ; Dec2: Forensic analysis, 3 days

    Rulset A
    A,B,C D
    YYY Dec1
    YYN Dec2
    YNY Dec2
    YNN Dec1
    NYY Dec2
    NYN Dec1
    NNY Dec2
    NNN Dec1

    Rulset B
    A,B,C D
    YYY Dec2
    YYN Dec2
    YNY Dec2
    YNN Dec1
    NYY Dec2
    NYN Dec1
    NNY Dec2
    NNN Dec1

    We will have some set of pre-defined rules as rulesets, one or more rulesets can be applied to a product/package
    Every ruleset will have "precedence", in case 2 rules clash we will pick with higher priority

    actions can be-

    • label: Do system upgrade, and timeline: 1 days

    Values:

    • Upgarde
    • Downgrade
    • Forensic Analysis
    • Reahability Analysis

    Sort by timelines

  4. pombredanne commented on Jul 16, 2026

    @pombredanne
    MemberAuthor

    For reference, building on SSVC see this from CISA:

    This provides a concrete process with sensible steps:
    Forensic Triage Steps

    • Step 1: Scoping
    • Step 2: Preserve and Collect Evidence
    • Step 3: Critical Patching and Stabilization
    • Step 4: Contain and Control
    • Step 5: Triage Analysis
    • Step 6: Escalation Decision
  5. moved this to In progress in 00-AboutCodePlanneron Jul 29, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions