Re: [atomic-devel] Python interface for atomic scan

[Brent Baude <bbaude redhat com>]

Hi Dharmit,

Comments inline.  Feel free to grab me on irc (nick: baude) and we can
discuss further.

On Tue, 2016-10-18 at 18:58 +0530, Dharmit Shah wrote:
> Hi,
> 
> I'm working on writing atomic scanner and would like to invoke them
> from
> a python program. However, I couldn't find documentation about it.
> Also,
> looking at the `Atomic/scan.py` and specifically scan function in
> that
> file, it seems like it is designed to be used from CLI only.
> 

Documentation:

https://github.com/projectatomic/atomic/blob/master/README-atomic-scan.
md
http://developers.redhat.com/blog/2016/05/02/introducing-atomic-scan-co
ntainer-vulnerability-detection/
http://developers.redhat.com/blog/2016/05/20/creating-a-custom-atomic-s
can-plug-in/

The latter two are a bit dated but the core should still be correct.


> At the moment, we're using Python's `subprocess` module to invoke
> `atomic scan` commands and then parse its output to figure the
> location
> where scanner would have output the file(s). Then we parse the json
> files and carry out tasks like notifying a user if there's something
> that needs to be worked upon based on the scan results. This doesn't
> seem to be a good way to go about it since any change in the way
> `atomic
> scan` outputs to stdout would cause things to break on our end.
> 

Have you tried using dbus to drive atomic scan.  This should work and
if it doesn't, I'll fix it.

> It'd be helpful if we can, instead of using `subprocess` module, have
> Python interface to invoke the scanner. This would make it simpler to
> know where the scan results got stored and directly access them.
> Also,
> is it possible to tell atomic scanner to use a specific file to
> output
> the results? I checked `atomic scan --help` but couldn't find one.
> 

The output files are pre-ordained.  However, there was another user
asking for something somewhat similar.  I have asked for an example but
haven't gotten a response.  Keep in mind that specifying an output
directory is probably more realistic.

> Thanks,
> Dharmit.
>