Avoid emitting Gemfile artifacts when the Gemfile is absent

When Gemfile.lock is scanned with artifact extraction enabled but the adjacent Gemfile is missing, this returns an artifact whose filename is the non-existent Gemfile. The SBOM code turns file-type artifacts into real file components, and GetBuildFileTrees treats those components as actual build files, so lockfile-only scans now report a bogus Gemfile node instead of omitting Ruby build-file relationships or falling back to the lockfile. Return nil or a lockfile-keyed bare artifact in the missing-Gemfile path.

Useful? React with 👍 / 👎.

Fixed. When no adjacent Gemfile exists, GetArtifact now returns nil instead of an artifact with a non-existent filename. Additionally, the artifact Name is now populated from the adjacent .gemspec (spec.name = "...") to provide a meaningful semantic identifier rather than leaving it empty.

Filter Gemfile path edges through the lockfile

When a Gemfile is stale or has conditionally evaluated gem ..., path: entries that are not selected in Gemfile.lock, this loop still emits every parsed path as a ProjectDep; the SBOM writer then creates file components and dependency edges for those paths, so GetBuildFileTrees can report Ruby project dependencies that are absent from the locked package graph. The existing Gemfile matcher treats the lockfile as the source of truth by skipping gems missing from Gemfile.lock, so artifact extraction should similarly only emit path edges for gems/specs present in the lockfile.

Useful? React with 👍 / 👎.

Not applying. The os.Stat check already filters out non-existent path targets, which covers the meaningful case. Cross-referencing the lockfile's PATH section would add complexity to guard against a stale/misconfigured Gemfile — a project state we treat as out of scope here.

this function calls collectPathsFromGemCalls which we are already calling few lines above, so I'm guessing we are possibly returning some duplicated entries. Can't we simply rely on the first collectPathsFromGemCalls ?

Fixed. The tree-sitter query in collectPathsFromGemCalls already matches gem() calls at any depth, so gems inside group blocks were being collected twice. Removed collectPathsFromGroupedGemCalls and simplified findGemsWithPath to a single call.

Done!

Skip self-resolving Gemfile path refs

When a Gemfile contains a valid local self-reference such as gem "my_gem", path: ".", targetGemfile cleans to the same path as gemfilePath, but this still emits it as a ProjectDep. The CycloneDX writer turns that into a build-file dependency from the Gemfile to itself, which is a false internal project edge and can confuse downstream consumers of the dependency graph; skip targets equal to the current Gemfile before appending.

Useful? React with 👍 / 👎.

Fixed. Added a guard before the dedup check to skip targetGemfile when it equals gemfilePath, preventing a self-loop in the build file tree.

Avoid matching gemspec self packages to Gemfile artifacts

When a gem project uses the standard gemspec form in its Gemfile, the lockfile contains the project gem itself in a PATH section while that package's BlockLocation remains Gemfile.lock because the Gemfile/gemspec matchers only enrich declared dependencies. Populating artifact.Name here makes findArtifact match that self package, so createFileComponents adds a dependency with Ref = Gemfile.lock pointing to this Gemfile, but addFileDependencies only emits the Gemfile file component. The generated CycloneDX SBOM therefore has a dangling lockfile→Gemfile dependency for ordinary gem projects; either avoid matching the current artifact to the self package or emit the self package location/component consistently.

Useful? React with 👍 / 👎.

Suppress fallback artifacts when Gemfile is missing

When artifact extraction scans a Ruby directory that has Gemfile.lock but no adjacent Gemfile, this nil return does not actually omit the artifact: ExtractDeps synthesizes a bare ScannedArtifact{Filename: f.Path()} whenever an ArtifactExtractor returns nil. Fresh evidence after the prior fix is that fallback path, so lockfile-only Ruby scans still emit a Gemfile.lock file component, and unfiltered GetBuildFileTrees can report the lockfile as a manifest build file instead of omitting Ruby build-file relationships for that directory.

Useful? React with 👍 / 👎.