CI use of codeaudit

[jurgenwigg]

Hi,
I would like to use codeaudit as a part of CI. Now, it only gives the report. It would be great to have some kind of simplified (table form maybe) output with proper exit code. Such feature would allow using codeaudit as a part of CI.

Example output:

$ codeaudit filescan --ci <package>
codeaudit 1.2.3
Security Scan Report:
> main.py
location: /home/user/python/package/main.py
Identified Security Weaknesses:
line 27: The pseudo-random generators in this module are not suitable for security purposes.
line 53: The pseudo-random generators in this module are not suitable for security purposes.

Output above is rough draft. I'm aware that introducing such feature would require few tasks. I offer my help in implementing it.

Best regards

[nocomplexity]

Thank you for opening this issue! I really appreciate you taking the time to share your thoughts and suggest this feature.

This feature is already on the roadmap , so I have already planned to implement something for CI use-cases!

My goal is to build this feature using the existing APIs wherever possible. I originally designed them with this exact feature in mind, and they are already heavily used.

The core API doing the heavy lifting here is the filescan API call.

You can check out this notebook for the output to see what this API-call does.

To make sure this feature integrates smoothly with various CI environments and meets your needs, I'd love to get a few more details about your use case:

• Which CI environment do you use? (e.g., GitHub, GitLab, Codeberg, SourceHut, BitBucket, Azure Pipelines, Jenkins, Travis, etc.)
• What output format do you prefer in your CI environment? (e.g., JSON or plain text)
• What is your primary scanning target? Do you want to scan 'local' packages within your own repository, or check also remote PyPI packages that your Python project depends on?

Thanks again, and looking forward to your thoughts!

Regards!

[jurgenwigg]

Thanks for the response!
Answering your questions:

• I'm using GitLab.
• Both JSON or plaintext are ok. Maybe even printing table formatted as a markdown one would be ok. JSON has that advantage that it can be used as an input to jq command.
• Main purpose is to scan local package files. Scanning remote packages is optional in our case, since we are using pip-audit to ensure security of dependencies.

I'll check the roadmap :)

[nocomplexity]

Thanks for this great input!
This really helps shape the initial functionality.

Regards!