/**
 * Hermetic lockfile/manifest-derived `SbomGenerator` (#613, epic #551 closes
 * the "HERMETIC-generator half of #610" per #613's scope note). Pure
 * TypeScript: reads a declared-dependency manifest already on disk (Node
 * `package-lock.json`, JVM `pom.xml`) and emits a real SPDX/CycloneDX
 * document via ./bom-writer.ts. No `syft`, no `docker buildx`, no
 * `cyclonedx-maven`, no network — every package in the resulting BOM comes
 * from parsing bytes chant already has locally.
 *
 * **What this backend is, and isn't.** A lockfile enumerates every declared
 * (transitive-resolved) dependency at the versions actually installed, so
 * the resulting SBOM is complete for **declared** dependencies — accurate
 * package identity and version for everything npm/Maven resolved. It is
 * **not** a container-layer scan: it cannot see OS packages baked into a base
 * image, binaries copied in by a Dockerfile `COPY`/`RUN`, or anything not
 * expressed as a lockfile entry. That deeper, image-layer-aware scan is
 * `syft`'s job (or BuildKit's native `--sbom` attestation) and stays exactly
 * where #610 already scoped it: the optional *deep* path, layered on top of
 * (never replacing) this hermetic baseline. See
 * docs/components/build-archive.mdx's SBOM section, updated alongside this
 * change, for the customer-facing version of this distinction.
 *
 * Registered as `forDir`/`forZip`/`forJar` implementations (the artifact
 * shapes a source-tree or packaged-but-uninspected artifact naturally maps
 * to); `forImage` still throws `SbomGeneratorNotImplementedError` — an image
 * SBOM needs either BuildKit's attestation or a container-layer scan, neither
 * of which a lockfile read can substitute for, so this backend deliberately
 * does not claim to cover it (mirrors how ./sbom-generator.ts's own
 * `notImplementedSbomGenerator` prefers a loud, specific failure over a
 * silently wrong answer).
 */
import { type BomPackage } from "./bom-writer.js";
import type { SbomGenerator } from "./sbom-generator.js";
/**
 * Parse a `package-lock.json` (v1, v2, or v3) into a flat `BomPackage[]`.
 * Prefers the v2/v3 `packages` map (flat, one entry per resolved install
 * location) since that's what `npm` >= 7 writes; falls back to the v1
 * `dependencies` tree for older lockfiles. De-duplicates by `name@version`
 * so a package appearing at multiple install paths (npm's dedup/hoisting)
 * contributes one BOM entry, matching how a real scanner reports installed
 * packages rather than filesystem paths.
 */
export declare function parseNpmPackageLock(content: string): BomPackage[];
/**
 * Parse the `<dependencies>` block of a `pom.xml` into a flat `BomPackage[]`.
 * Deliberately minimal (#613 calls this out as "add JVM pom.xml if cheap"):
 * a small tag-scoped regex walk over `<dependency>...</dependency>` blocks
 * extracting `groupId`/`artifactId`/`version`, no XML DOM dependency, no
 * property (`${...}`) resolution, no transitive resolution (Maven's own
 * dependency-mediation graph isn't reproducible without invoking `mvn`,
 * which would break the hermetic requirement). This is deliberately narrower
 * than the npm parser above: it covers the common case (a flat, literal
 * `<dependencies>` list) and documents its own limits rather than silently
 * mis-resolving a `${property}` version or a `<dependencyManagement>`
 * inheritance chain.
 */
export declare function parsePomXml(content: string): BomPackage[];
export interface LockfileSbomGeneratorOptions {
    /** Where generated SBOM documents are written on disk, as a sibling of the scanned path (see `sbomOutputPath`). Default: alongside the scanned manifest, named `sbom.<format>.json`. */
    outDir?: string;
    /** Clock override for deterministic tests. */
    now?: () => Date;
}
/** Default on-disk path for a generated SBOM: `<dir>/sbom.<format>.json`, matching #613's `sbom.<format>.json` naming convention. */
export declare function sbomOutputPath(dir: string, format: string): string;
/**
 * Build a hermetic `SbomGenerator` backed by lockfile parsing. `forDir` scans
 * `input.path` for a known manifest (`package-lock.json`, then `pom.xml`),
 * parses it into a `BomPackage[]`, and writes both the SBOM document (via
 * ./bom-writer.ts) to disk and returns it as an `SbomDocument`. `forZip`/
 * `forJar` reuse the same scan against the artifact's source directory
 * (the directory the archive was built from is the natural place a lockfile
 * lives — the packaged bytes themselves are not re-inspected, matching this
 * backend's "declared deps, not a binary scan" scope). `forImage` is not
 * implemented here: an image's dependency surface includes its base layers,
 * which no lockfile enumerates — see this module's doc comment.
 */
export declare function createLockfileSbomGenerator(options?: LockfileSbomGeneratorOptions): SbomGenerator;
/** Process-wide hermetic lockfile-backed `SbomGenerator`, ready to inject wherever ./sbom-generator.ts's `notImplementedSbomGenerator` default previously required an explicit real backend. */
export declare const lockfileSbomGenerator: SbomGenerator;
//# sourceMappingURL=lockfile-sbom-generator.d.ts.map