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

[Mark Esler]

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
>