More than one report format

[igor-sosnowicz]

Hi, I really appreciate your attention to details and polish of the application.
I would really welcome being able to obtain more than one file with report.

Use case:
I would like to scan an API endpoint and then generate a table report and also store results in report.yaml for archivisation purposes.

Thank your for your work.
Best regards!

[emmanuelgautier]

Hi @igor-sosnowicz

Thanks a lot for your kind words and for sharing your use case.

While it's already possible to generate reports in YAML or JSON format, the ability to output multiple formats at once could definitely be a useful addition.

If you have more context about how you’d ideally use this (e.g., where/how you archive the YAML, how you consume it later), feel free to share. It could help make this new feature even more useful for your setup.

I am also working on a GitHub Action that will help automate the archiving and displaying of reports in CI pipelines if it is your need.

[igor-sosnowicz]

Thank you for your reply!

I am developing an API and utilizing your scanner in one of the CI jobs.

Generating one report at a time is problematic. It requires running the same scanning process twice, which consumes both time and resources.

Speaking of my perfect use case, I would like to parse the YAML file with the report programmatically. Then, those with a CVSS score above a certain threshold would cause the CI job to fail. At the same time, I would archive a text file in a table format as an artifact of the CI job. This artifact could be reviewed in case of failure. It is much more convenient to manually inspect than a YAML file.

I am glad you mentioned the ongoing effort to create a GitHub Action. It would be helpful, but it is not a necessity.

Personally, I appreciate a rich open-source CLI tool (Vulnapi) more than any add-on to a proprietary platform (GitHub Action).

[github-actions]

Hello contributors!

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.
If you believe this issue is still relevant, please comment with your thoughts or re-open it.

Thank you for your contributions! 🙏

[igor-sosnowicz]

Hello,

I am curious if any progress has been made?

Best regards!

[emmanuelgautier]

Hi @igor-sosnowicz,

First of all, apologies for the late reply, and thank you again for taking the time to share your detailed use case.

Just to clarify: the GitHub Action I mentioned earlier is not a closed-source rewrite of VulnAPI, but simply a wrapper around the existing open-source build. The action itself is also open source, and you can find it here: cerberauth/vulnapi-action.

I’ve been thinking about your request, and I wonder if a more flexible solution would be not to have VulnAPI export multiple formats directly, but instead keep a single export (YAML and/or JSON) and let CI/CD-specific wrappers handle the formatting for their own use cases.

For example, in GitHub Actions the wrapper could read the exported YAML/JSON and output a human-readable table for the issues, pull requests, ... etc, while still letting you archive the machine-readable file. The same approach could be applied to GitLab, Jenkins, etc.

I personally like this architecture because it keeps VulnAPI’s core open and adaptable, while still making it easy to support different workflows.

What do you think about this approach?

[igor-sosnowicz]

Hi, @emmanuelgautier,

Thank you for your response.

Concerning the GitHub Action, I have already implemented the CI job independently and therefore do not require the integration of the aforementioned GitHub Action into my workflow to avoid duplicating efforts. However, I recognise its value for those who have not yet completed this task.

Your proposal is commendable for CI/CD pipeline applications; however, it does not align with users who prefer utilising the raw CLI. I believe that all functionality should be encapsulated within the application itself rather than relying on an external GitHub-dependent action. This approach also results in redundancy, as it necessitates writing that functionality for each CI/CD platform.

From my perspective, I would prefer to use a raw CLI. Nevertheless, I acknowledge that the primary objective of the tool you have developed is security. I see that increased automation can enhance efficiency, and CI/CD tools are indeed beneficial for reusability.

Thank you for taking the time to address my concerns.

[github-actions]

Hello contributors!

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.
If you believe this issue is still relevant, please comment with your thoughts or re-open it.

Thank you for your contributions! 🙏

[github-actions]

Hello contributors!

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.
If you believe this issue is still relevant, please comment with your thoughts or re-open it.

Thank you for your contributions! 🙏