Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WAS Integration #237

Open
cc-vy opened this issue Dec 18, 2023 · 3 comments
Open

WAS Integration #237

cc-vy opened this issue Dec 18, 2023 · 3 comments

Comments

@cc-vy
Copy link

cc-vy commented Dec 18, 2023

Will this now be possible with the new WAS API?
https://developer.tenable.com/reference/was-v2-vulnerabilities

@bobby-mack
Copy link

Hi @bkizer-tenable and @SteveMcGrath, just wondering if this is still on the radar for feature development, and any potential ETA that you can speak to as it relates on this Jira integration with Tenable for WAS based on the v2 release of this API? I don't think lack of engagement on this particular roadmap item is representative of reality as I believe many other Tenable + Jira clients are eagerly anticipating this and expecting it as evidenced based on previously asked and answered inquiries when WAS was still on the v1 API. Any kind of update would be much appreciated!

@SteveMcGrath
Copy link
Collaborator

Sadly that API still has some significant issues when it comes to bulk export. If you note that the search API doesn't return enough detail and forces you to pull every single finding detail in order to get the information. This has a huge issue at scale and we would like to avoid making calls that could take hours to complete.

@bobby-mack
Copy link

Thanks for the transparency on this @SteveMcGrath; I too experienced this pain regarding the API, so that immediately resonates with me. I wonder then, if there's some future opportunity to consolidate the "search" and "get details" endpoints to emulate how traditional vulns are handled for the bulk export? I realize it may not be scalable to your point and I question if this is done by design to rate-limit calls because the plugin output on some of these findings is quite verbose. Not entirely sure if possible, but in the interim I suspect we may just try to pull the basic top-level information with "search" and simply append the "get details" of said vulns (looping through an array of vuln IDs) as raw JSON in the output field of the original or something like that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants