No reaction when submitting projects
59 views
Skip to first unread message
johanna curiel curiel
Apr 22, 2026, 3:30:29 AMApr 22
to Leaders
Hi OWASP Leaders,
It's been a while since I last reached out to the group, so I hope everyone is doing well.
I'm following up on a project submission I made approximately three months ago. After an initial response indicating the submission would be reviewed by end of January, I haven't received any further updates — and I have to be honest, the silence has been quite discouraging.
I'd like to understand:
- Is there currently an active team or process handling new project submissions?
- If capacity is limited, I'd be happy to support these activities as a volunteer, with a four-eyes principle in mind to ensure proper oversight and quality.
I believe active project intake is important for the health and growth of our community, and I'd love to contribute rather than just wait on the sidelines.
It's been a while since I last reached out to the group, so I hope everyone is doing well.
I'm following up on a project submission I made approximately three months ago. After an initial response indicating the submission would be reviewed by end of January, I haven't received any further updates — and I have to be honest, the silence has been quite discouraging.
I'd like to understand:
- Is there currently an active team or process handling new project submissions?
- If capacity is limited, I'd be happy to support these activities as a volunteer, with a four-eyes principle in mind to ensure proper oversight and quality.
I believe active project intake is important for the health and growth of our community, and I'd love to contribute rather than just wait on the sidelines.
Johanna Curiel
OWASP Volunteer
Starr Brown
Apr 22, 2026, 10:53:22 AMApr 22
to Leaders, johanna curiel curiel
Hi Johanna -
Thank you for raising your concerns. I personally manage OWASP project approvals and, like most in our industry, feel like we've lived an entire year within Q1. We have been buried by both verbose AI proposals and AI slop, along with the usual project proposals. New projects are approved every week, and I should be caught up by the end of the month. You are always welcome to contact me directly for specific questions.
starr...@owasp.com though Slack is preferred
Thanks. Starr
Paulo Silva
Apr 23, 2026, 4:10:23 AM (13 days ago) Apr 23
to Leaders, Starr Brown, johanna curiel curiel
Hi Johanna,
I understand when you say "the silence has been quite discouraging".
To avoid loosing the momentum and assuming your biggest interest is the community, you can start/publish the project on your own (GitHub) and later donate it to OWASP.
This is how OWASP Go Secure Coding Practices became an OWASP project.
To avoid loosing the momentum and assuming your biggest interest is the community, you can start/publish the project on your own (GitHub) and later donate it to OWASP.
This is how OWASP Go Secure Coding Practices became an OWASP project.
Cheers,
Paulo A. Silva
OWASP Appsec Days Portugal 2026 - https://appsecdays.pt/
OWASP API Security Project - Project Co-Leader
OWASP Go Secure Coding Practices Guide - Project Co-Leader
OWASP API Security Project - Project Co-Leader
OWASP Go Secure Coding Practices Guide - Project Co-Leader
OWASP Beja Chapter Co-Leader
johanna curiel curiel
Apr 23, 2026, 6:39:14 AM (13 days ago) Apr 23
to Paulo Silva, Leaders, Starr Brown
Yes, that’s exactly what I did. However, as you know, simply publishing something on GitHub won’t attract attention on its own , there needs to be some promotion behind it. That’s precisely where OWASP can help by supporting and amplifying open-source projects like this.
Johanna Curiel
OWASP VolunteerPaulo Silva
Apr 23, 2026, 7:52:09 AM (13 days ago) Apr 23
to johanna curiel curiel, Leaders, Starr Brown
Meanwhile, would you mind sharing the project page/repo?
Paulo A. Silva
OWASP Appsec Days Portugal 2026 - https://appsecdays.pt/
OWASP API Security Project - Project Co-Leader
OWASP Go Secure Coding Practices Guide - Project Co-Leader
OWASP API Security Project - Project Co-Leader
OWASP Go Secure Coding Practices Guide - Project Co-Leader
OWASP Beja Chapter Co-Leader
johanna curiel curiel
Apr 23, 2026, 8:32:52 AM (13 days ago) Apr 23
to Paulo Silva, Leaders, Starr Brown
I've been working on a PoC that automates VEX (Vulnerability Exploitability eXchange) document generation from SBOMs using an AI agent on Microsoft Azure AI Foundry.
I created a website for awareness under sbomvex.info or sbomvex.org to promote the use of Vex and automation with agents
See documentation attached and can be found here:
and more technical here:
https://img1.wsimg.com/blobby/go/ff254553-9e9c-4c72-9933-76a9e29f3638/downloads/8500e55a-36b9-4f75-b127-345699d71ca4/A%20Practical%20Guide%20to%20Implementing%20SBOM%20and%20VEX.pdf?ver=1769346401765
SBOMs tell you what is in your software — VEX tells you whether it matters. Producing accurate VEX documents manually at scale is where things break down today.
A Python script posts a CycloneDX/SPDX SBOM to a Foundry-hosted agent via the azure-ai-projects SDK. The agent — currently running grok-4-20-non-reasoning — performs a version-aware CVE lookup per component and returns a valid CycloneDX VEX 1.5 JSON document. From a live run: lodash v4.17.21 is not_affected by CVE-2019-10744 because it only affects versions below 4.17.12, while openssl v3.0.7 is flagged affected by three CVEs (CVSS 7.4, 7.5, and 5.9) with a recommendation to upgrade to 3.0.8 or later. Not "openssl is vulnerable" , but "this exact purl at this exact version is in the affected range." That's the precision VEX requires.
A Python script posts a CycloneDX/SPDX SBOM to a Foundry-hosted agent via the azure-ai-projects SDK. The agent — currently running grok-4-20-non-reasoning — performs a version-aware CVE lookup per component and returns a valid CycloneDX VEX 1.5 JSON document. From a live run: lodash v4.17.21 is not_affected by CVE-2019-10744 because it only affects versions below 4.17.12, while openssl v3.0.7 is flagged affected by three CVEs (CVSS 7.4, 7.5, and 5.9) with a recommendation to upgrade to 3.0.8 or later. Not "openssl is vulnerable" , but "this exact purl at this exact version is in the affected range." That's the precision VEX requires.
The current use of a large reasoning model is intentional for the prototype phase, but the plan is to replace it with a fine-tuned 1–7B model trained on labelled SBOM+VEX pairs — faster, cheaper, and deployable in air-gapped environments.
The bigger goal is a shared, versioned database of VEX assertions for the most common open source packages across npm, Maven, PyPI, and Go , think OSV but for exploitability. The agent pipeline would first check the database, and on a miss generate a new assertion, flag it for human review, and contribute it back. AI bootstraps the knowledge base; humans audit it. This integrates directly with Dependency-Track, which already consumes VEX natively.
The community database only works with peer review before assertions are committed, VEX carries compliance weight and human sign-off stays in the loop.
Happy to share the source and a demo SBOM. Interested in collaborating on the database schema, tooling, or governance? Happy to hear more from you ;-)
Best regards
Johanna Curiel
OWASP Volunteer
Steve Springett
Apr 23, 2026, 10:03:05 AM (13 days ago) Apr 23
to johanna curiel curiel, Leaders, Starr Brown, Paulo Silva
Johanna,
I'd genuinely like to see more of this project as it develops. The intersection of AI assisted analysis and SBOM/VEX workflows is an area worth exploring, and I appreciate the effort that's gone into the PoC. One organization I know spends roughly $500K USD per VEX document for a product version. The analysis required is not something that I’ve seen existing tools be good at. AI doesn’t have a large enough context window, and SAST just falls short everywhere.
A few thoughts to share with the Leaders list as this moves forward.
On terminology, what the PoC generates looks closer to VDR than VEX. The distinction matters because VEX is a negative security advisory requiring specific analysis and justifications, not a version-range check against a CVE, even for components not included in a given product. I wrote about this here for anyone who wants background: https://owasp.org/blog/2023/02/07/vdr-vex-comparison.
The deeper challenge is that VEX determinations are contextual to the consuming product. Whether a CVE matters depends on reachability, call paths, configuration, existing controls, and how the library composes with the rest of the application. This is why existing OWASP guidance, including the Threat Modeling Cheat Sheet and ASVS, emphasizes multi-step attack analysis and chained vulnerabilities over component-level views. A shared database of generic VEX assertions would need to account for this, or it risks giving consumers determinations that were never valid for their product and conflicting with existing OWASP guidance.
That said, I think there's a genuinely valuable research direction here that could give the project a focused mission: identifying the narrow class of libraries where a VEX assertion holds regardless of consuming context. These cases do exist, for example, a CVE affecting code that was never present in a given version, or a dependency removed entirely. Scoping the project to build that high-confidence subset first, with clear inclusion criteria, would yield a defensible and useful result. It would also naturally separate the generation tooling from the shared database question, which I think benefits from its own discussion with the CycloneDX, Dependency-Track, and SCVS communities.
Happy to talk through any of this.
I'd genuinely like to see more of this project as it develops. The intersection of AI assisted analysis and SBOM/VEX workflows is an area worth exploring, and I appreciate the effort that's gone into the PoC. One organization I know spends roughly $500K USD per VEX document for a product version. The analysis required is not something that I’ve seen existing tools be good at. AI doesn’t have a large enough context window, and SAST just falls short everywhere.
A few thoughts to share with the Leaders list as this moves forward.
On terminology, what the PoC generates looks closer to VDR than VEX. The distinction matters because VEX is a negative security advisory requiring specific analysis and justifications, not a version-range check against a CVE, even for components not included in a given product. I wrote about this here for anyone who wants background: https://owasp.org/blog/2023/02/07/vdr-vex-comparison.
The deeper challenge is that VEX determinations are contextual to the consuming product. Whether a CVE matters depends on reachability, call paths, configuration, existing controls, and how the library composes with the rest of the application. This is why existing OWASP guidance, including the Threat Modeling Cheat Sheet and ASVS, emphasizes multi-step attack analysis and chained vulnerabilities over component-level views. A shared database of generic VEX assertions would need to account for this, or it risks giving consumers determinations that were never valid for their product and conflicting with existing OWASP guidance.
That said, I think there's a genuinely valuable research direction here that could give the project a focused mission: identifying the narrow class of libraries where a VEX assertion holds regardless of consuming context. These cases do exist, for example, a CVE affecting code that was never present in a given version, or a dependency removed entirely. Scoping the project to build that high-confidence subset first, with clear inclusion criteria, would yield a defensible and useful result. It would also naturally separate the generation tooling from the shared database question, which I think benefits from its own discussion with the CycloneDX, Dependency-Track, and SCVS communities.
Happy to talk through any of this.
— Steve
On Apr 23, 2026 at 7:32 AM -0500, johanna curiel curiel <johanna...@owasp.org>, wrote:
I've been working on a PoC that automates VEX (Vulnerability Exploitability eXchange) document generation from SBOMs using an AI agent on Microsoft Azure AI Foundry.I created a website for awareness under sbomvex.info or sbomvex.org to promote the use of Vex and automation with agentsSee documentation attached and can be found here:and more technical here:https://img1.wsimg.com/blobby/go/ff254553-9e9c-4c72-9933-76a9e29f3638/downloads/8500e55a-36b9-4f75-b127-345699d71ca4/A%20Practical%20Guide%20to%20Implementing%20SBOM%20and%20VEX.pdf?ver=1769346401765
SBOMs tell you what is in your software — VEX tells you whether it matters. Producing accurate VEX documents manually at scale is where things break down today.
A Python script posts a CycloneDX/SPDX SBOM to a Foundry-hosted agent via the azure-ai-projects SDK. The agent — currently running grok-4-20-non-reasoning — performs a version-aware CVE lookup per component and returns a valid CycloneDX VEX 1.5 JSON document. From a live run: lodash v4.17.21 is not_affected by CVE-2019-10744 because it only affects versions below 4.17.12, while openssl v3.0.7 is flagged affected by three CVEs (CVSS 7.4, 7.5, and 5.9) with a recommendation to upgrade to 3.0.8 or later. Not "openssl is vulnerable" , but "this exact purl at this exact version is in the affected range." That's the precision VEX requires.
The current use of a large reasoning model is intentional for the prototype phase, but the plan is to replace it with a fine-tuned 1–7B model trained on labelled SBOM+VEX pairs — faster, cheaper, and deployable in air-gapped environments.
The bigger goal is a shared, versioned database of VEX assertions for the most common open source packages across npm, Maven, PyPI, and Go , think OSV but for exploitability. The agent pipeline would first check the database, and on a miss generate a new assertion, flag it for human review, and contribute it back. AI bootstraps the knowledge base; humans audit it. This integrates directly with Dependency-Track, which already consumes VEX natively.
The community database only works with peer review before assertions are committed, VEX carries compliance weight and human sign-off stays in the loop.
Happy to share the source and a demo SBOM. Interested in collaborating on the database schema, tooling, or governance? Happy to hear more from you ;-)
Best regards
<Screenshot 2026-04-23 at 14.09.28.png>
--
You received this message because you are subscribed to the Google Groups "Leaders" group.
To unsubscribe from this group and stop receiving emails from it, send an email to leaders+u...@owasp.org.
To view this discussion visit https://groups.google.com/a/owasp.org/d/msgid/leaders/CACxry_3ABiQwkshBf92QmZBCgkaXqRL-5ZA3NWUp73V_o_jKAA%40mail.gmail.com.
johanna curiel curiel
Apr 23, 2026, 10:49:02 AM (13 days ago) Apr 23
to Steve Springett, Leaders, Starr Brown, Paulo Silva
Hi Steve
Thank you, this is exactly the kind of feedback that sharpens the project.
The VDR vs VEX distinction is a fair and important correction. You are right that what the PoC currently produces is closer to VDR territory, a structured record of vulnerability relevance per component, rather than a full VEX assertion with the justification and context that a negative security advisory requires. I will make sure the terminology is accurate going forward, both in the tooling and in how I describe it to the community.
On the $500K figure, that number actually makes the case for why this problem is worth solving, and also why getting the scope right matters. If that cost reflects the depth of analysis required, reachability, call paths, configuration, chained vulnerabilities and so on, then a tool that shortcuts that analysis without accounting for consuming product context is not solving the problem, it is creating a false sense of coverage. That is a real risk and your point about conflicting with existing OWASP guidance on multi-step attack analysis is well taken.
On the narrow class of high-confidence assertions you describe, this is actually something I already explored in my own prior work. In this article on supply chain vulnerabilities in the Kubernetes Java client, I used static code analysis to trace whether CVEs in that library actually propagated to products consuming it, and in several cases they did not, because the vulnerable code paths were simply never reached:
The VDR vs VEX distinction is a fair and important correction. You are right that what the PoC currently produces is closer to VDR territory, a structured record of vulnerability relevance per component, rather than a full VEX assertion with the justification and context that a negative security advisory requires. I will make sure the terminology is accurate going forward, both in the tooling and in how I describe it to the community.
On the $500K figure, that number actually makes the case for why this problem is worth solving, and also why getting the scope right matters. If that cost reflects the depth of analysis required, reachability, call paths, configuration, chained vulnerabilities and so on, then a tool that shortcuts that analysis without accounting for consuming product context is not solving the problem, it is creating a false sense of coverage. That is a real risk and your point about conflicting with existing OWASP guidance on multi-step attack analysis is well taken.
On the narrow class of high-confidence assertions you describe, this is actually something I already explored in my own prior work. In this article on supply chain vulnerabilities in the Kubernetes Java client, I used static code analysis to trace whether CVEs in that library actually propagated to products consuming it, and in several cases they did not, because the vulnerable code paths were simply never reached:
That is exactly the kind of context-independent NOT_AFFECTED assertion you are describing: not a version range check, but a structural conclusion that holds regardless of how the consuming product is built. Those are the cases worth putting in a shared database first, with clear inclusion criteria and a transparent review process that the CycloneDX, Dependency-Track and SCVS communities can engage with.
The separation you suggest between the generation tooling and the shared database governance also makes sense architecturally. The agent bootstraps and accelerates analysis, but what gets committed to a shared database deserves its own process and its own conversation.
I would very much welcome a discussion with you and whoever else from those communities wants to be involved. Happy to set something up.
The separation you suggest between the generation tooling and the shared database governance also makes sense architecturally. The agent bootstraps and accelerates analysis, but what gets committed to a shared database deserves its own process and its own conversation.
I would very much welcome a discussion with you and whoever else from those communities wants to be involved. Happy to set something up.
Reply all
Reply to author
Forward
0 new messages