[ubuntu-hardened] Tooling question about collecting changelog info for security updates

[Mike McCracken (mikmccra)]

Hi Mark, thanks! I've looked at the OVAL feeds before but I didn't end up using them yet, I should revisit.

That cve tracker is a ton of useful info, it looks like I should be able to use or repurpose one of the scripts in there for sure.

As an aside, about trivy, I am actually not up to speed on its data sources, but it seems to be 
aware of ubuntu version numbering. 
I have definitely had "fun" dealing with scanners that were not, though!

Thanks again,
-mike

> On May 31, 2024, at 3:44 PM, Mark Esler <mark.esler at canonical.com> wrote:
> 
> Hello Mike o/
> 
> Our OVAL feed may be what you are looking for [0]. OVAL is used widely
> for this kind of data, but the industry will be shifting to other
> formats like OSV and OpenVEX soon.
> 
> OVAL feeds are generated from the Ubuntu CVE Tracker [1]. Each time
> Ubuntu Security works with a CVE we update this git repo. It describes
> the state of a CVE in Ubuntu. OVAL will likely be easier to parse for
> your needs.
> 
> (The UCT repo also has scripts like `./scripts/pkg_history $PKG_NAME`)
> 
> I cannot speak to Trivy. Some scanners use Ubuntu's OVAL data and work
> well. If the scanner finds more CVEs than OVAL, it is likely that the
> scanner is unaware of Ubuntu version numbering.
> 
> Cheers,
> Mark
> 
> [0] https://ubuntu.com/security/oval
> [1] https://git.launchpad.net/ubuntu-cve-tracker/
> 
> On Fri, May 31, 2024 at 10:35:55PM +0000, Mike McCracken (mikmccra) wrote:
>> Hi, thanks for the reply! Not stupid, image scanning is definitely a part of what I'm doing.
>> Actually, we will often rebuild an image because of a specific CVE that was found by a scan
>> (and we do use trivy, it is part of the Zot OCI image registry[1].)
>> 
>> However, the question I want to answer is not "what vulns are present in this image",
>> instead it is "what vulns were fixed between this build of the image vs that build".
>> 
>> Thanks!
>> -mike
>> 
>> [1]https://zotregistry.dev/v2.1.0/user-guides/zli/?h=scan#scanning-images-for-known-vulnerabilities
>> 
>>> On May 31, 2024, at 3:18 PM, Marcos Alano <marcoshalano at gmail.com> wrote:
>>> 
>>> Hi, 
>>> 
>>> I probably did not understand your question so my suggestion may sound stupid, but you could scan your image using Trivy to get the errors and produce a report in JSON that could be parsed by machine. 
>>> 
>>> Again, I think I misunderstood your question. Sorry. 
>>> 
>>> Marcos Alano
>>> 
>>> On Fri, May 31, 2024, 19:07 Mike McCracken (mikmccra) <mikmccra at cisco.com> wrote:
>>> Hi, I am wondering if there is already a tool to generate this kind of report about 
>>> CVE-driven and other security fixes in the archive:
>>> 
>>> I have container images based on ubuntu being built at regular intervals, and 
>>> we are updating all packages to get the latest security updates at image build time.
>>> In order to be able to tell if a build of my images has a given fix, I produce a list
>>> of all packages that were installed and their versions.
>>> 
>>> What I would like to do is given two such lists, get all the changelogs (or just CVE IDs)
>>> for each update that happened between those lists.
>>> 
>>> So for example using recent jammy releases of git:
>>> at Time T, I build an image that has a list including git like this:
>>> 
>>> ```
>>> git 1:2.34.1-1ubuntu1.9
>>> ```
>>> 
>>> and then Time T+1 I rebuild and get a git that's two package releases newer:
>>> 
>>> ```
>>> git 1:2.34.1-1ubuntu1.11
>>> ```
>>> 
>>> Then I want to be able to produce a file where I get the logs for each increment of the package
>>> between those version
>>> 
>>> ```
>>> # git
>>> 1:2.34.1-1ubuntu1.9 - 1:2.34.1-1ubuntu1.11
>>> 
>>> ## 1:2.34.1-1ubuntu1.10 changes
>>> 
>>> git (1:2.34.1-1ubuntu1.10) jammy; urgency=medium
>>> .
>>> * Fix issue where untracked files are not recovered during a stash
>>> pop/apply operation when a merge conflict is present. Untracked
>>> files are now correctly restored regardless if a conflict is
>>> present or not. (LP: #2026319)
>>> - d/p/lp-2026319-stash-do-not-return-before-restoring-untracked-files.patch
>>> 
>>> ## git (1:2.34.1-1ubuntu1.11) jammy-security; urgency=medium
>>> .
>>> * SECURITY UPDATE: Facilitation of arbitrary code execution
>>> - debian/patches/CVE-2024-32002.patch: submodule paths
>>> must not contains symlinks in builtin/submodule--helper.c.
>>> - CVE-2024-32002
>>> 
>>> ...etc
>>> ```
>>> 
>>> This info is available on launchpad easy enough for manual looking,
>>> but it doesn't seem to be exposed in a straightforward way
>>> for scripting to automate the whole list. So I thought I'd ask if anyone
>>> has already tackled this, or knows of a better way to get this info,
>>> and then I can just use their work and praise their name.
>>> 
>>> Thanks!
>>> -mike
>> 
>