jf audit: PEP 621 Support for Poetry Projects

Describe the bug

Upshot: jf audit fails to scan the dependencies in a Poetry project that uses Python's standardized metadata format.

Background:

Poetry's 2.0 release introduced support for the standard Python project metadata specification defined in PEP 621. For the purposes of this issue, the relevant change is the ability to declare the dependencies of a Poetry-managed project in a format that is agnostic to any given package manager. For now, Poetry supports both this standard specification as well as its proprietary format. Regardless of how the dependencies are specified, it will produce an equivalent lock file in which only the "content-hash" will differ. Poetry offers a nice summary of dependency specification behavior here, but I will provide a short example of the new behavior in the "Current behavior" field.

When running jf audit on a project using the PEP 621 spec to declare dependencies instead of the poetry.dependencies table, jf finds no dependencies. If I move the dependencies to the poetry.dependencies table and run poetry lock, I see the lock file is unchanged except for the hash, but jf audit now works as expected.

Current behavior

Here is how a Poetry project might have looked prior to 2.0:

[project]
name = "jfrog-mre"
version = "0.1.0"
description = ""
authors = [
    {name = "John Doe",email = "example@example.com"}
]
readme = "README.md"

[tool.poetry]
packages = [{include = "jfrog_mre", from = "src"}]

[tool.poetry.dependencies]
python = ">=3.13"
aiostream = ">=0.7.0,<0.8.0"

[build-system]
requires = ["poetry-core>=2.0.0,<3.0.0"]
build-backend = "poetry.core.masonry.api"

Running

poetry lock
jf audit --poetry

on this project yields the expected output

Vulnerable Dependencies
┌──────────────────── ┐
│ ✨ No vulnerable dependencies were found ✨ │

If I modify the project metadata to use the PEP 621 syntax:

[project]
name = "jfrog-mre"
version = "0.1.0"
description = ""
authors = [
   {name = "John Doe",email = "example@example.com"}
]
readme = "README.md"

# this is the important change
requires-python = ">=3.13"
dependencies = [
    "aiostream (>=0.7.0,<0.8.0)"
]

[tool.poetry]
packages = [{include = "jfrog_mre", from = "src"}]

[build-system]
requires = ["poetry-core>=2.0.0,<3.0.0"]
build-backend = "poetry.core.masonry.api"

and re-lock

poetry lock

I see no real modification to the dependencies.

diff --git a/poetry.lock b/poetry.lock
index 0d3c2a0..e589f79 100644
--- a/poetry.lock
+++ b/poetry.lock
@@ -33,4 +33,4 @@ files = [
 [metadata]
 lock-version = "2.1"
 python-versions = ">=3.13"
-content-hash = "778650c6e329a706cab7f61d4dcd2898837a1e5fd40f6675a3b5388489183176"
+content-hash = "b5186d11c92a12923c8b3316939bcfa0cd91669bb1c9ccdf51250e9e759cd6f7"

Yet, running jf audit --poetry now yields

13:10:50 [🔵Info] Log path: .../.jfrog/logs/jfrog-cli.2025-09-05.13-10-50.46472.log
13:10:53 [🔵Info] Trace ID for JFrog Platform logs: 31070edaf54eac57
13:10:53 [🚨Error] target '.../repos/tmp/jfrog-mre [poetry]' errors:
failed to generate SBOM for .../repos/tmp/jfrog-mre: failed to build dependency tree: no dependencies were found. > Please try to build your project and re-run the audit command

Reproduction steps

• Install the latest version (or at least 2.0+) of Poetry: https://python-poetry.org/docs/#installation
• Create a new Poetry project. Via Poetry's CLI, you can run poetry new jfrog-mre
• From the project's root, add a dependency via Poetry's CLI, e.g. poetry add aiostream
• Run jf audit --version

Expected behavior

jf audit should work with Poetry projects that use the PEP 621 project spec.

JFrog CLI-Security version

2.78.9

JFrog CLI version (if applicable)

jf version 2.78.9

Operating system type and version

macOS 15.6.1, MacBook Pro M2 Pro

JFrog Xray version

No response

Run the reproduction with Poetry 2.x and jf audit --poetry, then trace the Poetry dependency discovery used by the audit command. Compare handling of [tool.poetry.dependencies] with [project].dependencies and add regression coverage for the PEP 621 form; done means the dependency tree is found and the audit no longer reports that no dependencies were found.