[Feature Request] - Provide vulnerability data in machine readable format

[yavor-atanasov]

Is your feature request related to a problem? Please describe. We'd like to be able to run vulnerability scans against package metadata extracted from AMIs. For this we need machine readable format (JSON or other) of the list of discovered vulnerabilities (https://alas.aws.amazon.com/alas2022.html) which includes the evaluation criteria for each one (e.g. https://alas.aws.amazon.com/AL2022/ALAS-2022-117.html).

Describe the solution you'd like For more context, we have thousands of services running in autoscaling groups across hundreds (~700) of AWS accounts. Our Bakery service bakes the AMI for each of those services and at the point of baking we extract the RPM metadata of each AMI. So instead of running scanning agents on each of those thousands of instances and try to collect that data, we scan the extracted package metadata for each AMI. It’s a more efficient and scalable approach.

We currently do this for Centos based AMIs using OVAL data published by Red Hat:

• https://www.redhat.com/security/data/oval/com.redhat.rhsa-RHEL8.xml

• https://www.redhat.com/security/data/oval/com.redhat.rhsa-RHEL7.xml

  As we potentially migrate to using Amazon Linux, we'd like to keep our ability to scan for vulnerabilities and notify relevant parties.

Describe alternatives you've considered We've looked at AWS Inspector as a different approach of doing vulnerability scans, but that relies on an agent being run on every single EC2 instance. That doesn't scale that well and makes the aggregation of that data centrally very difficult as AWS doesn't provide an organisation view of that data.

Supposedly AWS inspector already has access to vulnerability data in the format we require in order to do its scans?

Additional context n/a

[tomcart]

Are there any plans to provide this data?

[stewartsmith]

I've actually just recently been working on a lot of cleanup and refactoring of the code that renders updateinfo.xml and the ALAS web site so that it could unblock work on this kind of thing.

There was a bunch of legacy code that got in the way of a variety of improvements both for us internally in updating the information there, as well as providing information to customers in a variety of formats.

So while I don't have a timeline, it is something we want to provide, and the necessary precursor work to ensure we can implement such a thing with confidence is being done.