Antonino Sabetta

@sumeetpatil How would you do that in bash? How to determine which files to checkout exactly? That can be added to the script easily, but we need to know how...

basically we need to implement this https://github.com/eclipse/steady/blob/fe8c6af35f887f7df98b02d9034b8d3e414588b2/repo-client/src/main/java/org/eclipse/steady/git/GitClient.java#L524 in bash

Hi @sumeetpatil, you mean we should have a GH action to check statements in our own repo (possibly invoking something like `kaybee check `)?

Proposed solution (thanks @henrikplate !): keep track of the time when statements about a given vuln. were last reconciled; then, compare timestamp of each candidate statement with the last resolution...

Yes, and that's easier to implement but the finer-grained approach might be useful in practice: if we have one `last_reconciled` timestamp per vulnerability, we can just set that timestamp to...

I need to think about it, you're probably right, this simpler approach might be all we need. As for the second part: during and after merging, the statement is annotated...

For each "reconciled statement" i keep the full list of candidate statements that were considered, and for each of them, I keep the information of the source they came from....

Why a single `last_run` timestamp is not enough, and we need finer, per-vulnerability , timestamps: Imagine we run `kaybee merge -p ` (for example, policyA could be `strict`): the result...

A simpler solution, with no timestamps involved: When reconciling statements, we can simply check if we have already considered that set of candidates in a previous (successful) reconciliation. If the...

For example, this paper collects 3750 vulnerabilities from NVD (note: for some reason they rely on crawling and scraping instead of just downloading the data feeds from the NVD): https://dl.acm.org/doi/10.1145/3379597.3387501