Collect vulnerabilities from Amazon Linux
See https://alas.aws.amazon.com/ There are two variants: AL and AL2
Essentially we want to scrape/mine/consume the pages at https://alas.aws.amazon.com/ and https://alas.aws.amazon.com/alas2.html .
Taking it up @sbs2001 @pombredanne !
I checked https://alas.aws.amazon.com/ but I found that the table does not contain fixed and affected versions . I even checked the advisory url( eg https://alas.aws.amazon.com/ALAS-2011-1.html )but did not find the same. @sbs2001 @pombredanne can you help me.
@tushar912 the new packages mentioned at the advisory page are the fixed packages. It seems there is no easy way to obtain exact affected packages so you can skip finding them.
@sbs2001 I am still confused .Currently what I conclude is to create a PackageURL object we need version .But currently what I find is that the table doesn't provide any thing related to version of the package which is affected.Please help.
@tushar912 in https://alas.aws.amazon.com/ALAS-2011-1.html I can see this:
- Affected Packages: httpd (no version alright for now and not much data)
- New packages (e.g. where this is fixed):
- i686: httpd-devel-2.2.21-1.18.amzn1.i686 httpd-debuginfo-2.2.21-1.18.amzn1.i686 httpd-2.2.21-1.18.amzn1.i686 httpd-tools-2.2.21-1.18.amzn1.i686 mod_ssl-2.2.21-1.18.amzn1.i686
- noarch: httpd-manual-2.2.21-1.18.amzn1.noarch
- src: httpd-2.2.21-1.18.amzn1.src
- x86_64: mod_ssl-2.2.21-1.18.amzn1.x86_64 httpd-tools-2.2.21-1.18.amzn1.x86_64 httpd-2.2.21-1.18.amzn1.x86_64 httpd-devel-2.2.21-1.18.amzn1.x86_64 httpd-debuginfo-2.2.21-1.18.amzn1.x86_64
From that I can therefore infer:
- all these packages versions are fixed (and we can parse RPMs nevra with https://github.com/nexB/scancode-toolkit/blob/develop/src/packagedcode/nevra.py)
- whatever were the versions BEFORE these versions are vulnerable
Does this make sense?
Ok . I understood New Packages are the ones that are fixed and whatever are before were affected.
ok, sorry it it felt like a rehash ....that said we may not have a version that is affected, but rather a version range. @sbs2001 what do you think? that looks like a good use case for the ranges/spec?