Add optional policy parameter for vulnerabilities older than N days

[emaildanwilson]

fixes #149
cc @nurmi

Let me know how this looks, and what other changes would need to be made for it to be included. How are tests handled for policy filters like this? Does the cli need to be updated to include the creation date in vulnerability output?

[zhill]

Thanks @emaildanwilson ! We'll take a look at comment here!

[emaildanwilson]

Any chance someone could take a look this week?

[nurmi]

hello!

We’re finishing up some feature work, and you’ll see some flurry of work in the next couple of weeks as we gear up for the next oss engine release - your pr is on the list for adressing for that next release - stay tuned and appreciate your patience!

[zhill]

I think the primary question is the semantics you're trying to achieve. The created_at timestamp on vulnerability records in anchore is when the db entry was created, not when the vulnerability was created in in the upstream source. So, for example, none of the created_at timestamps will be older than the anchore deployment date itself. Is that what you're expecting?

[emaildanwilson]

Yes, given that some of the sources do not contain a discovery date it seems like it's the best we can do right now. Aside from the caveat of the installation being brand new or the local scan database getting deleted/recreated, the created_at date should match the discovery date within the polling period. Using the created_at date for feeds where the discovery date is not available might create even more confusion. I'm open to ideas if there are ways we could make this better.

[zhill]

Ack, just wanted to make sure the semantics were understood and acceptable. I tend to agree that there isn't a cleaner way to do it in this case given the diversity of input data.

[zhill]

One little naming change for broader policy naming consistency, but otherwise looks good.

[zhill]

Thanks! Much appreciated, this is a super-useful feature.