Alex Goodman
c4800b2393
* test(dotnet): speed up pe fixture tests the pe package took ~90s under -race, nearly all of it loading docker archive fixtures. two things: the three bundle fixtures published with `SelfContained=true`, so each `hello.exe` carried a full .NET runtime (~60MB, 33MB tar). the bundle format is what those fixtures exercise and it is identical framework-dependent, so they now publish with `SelfContained=false` (160KB exe, 2MB tar). the race detector multiplies the layer inflate + diffID hashing by ~15x, which is why the size mattered so much. `fixtureFile` also loaded the image and built a squashed resolver per table row, so `image-net8-app` was loaded four times for four files in it. resolvers are now built once per distinct fixture from the parent test. 87s -> 28.5s under -race, and ~60MB less fixture cache. Signed-off-by: Alex Goodman <wagoodman@users.noreply.github.com> * fix(dotnet): read the right file type from V1 single-file bundles V1 bundles (.NET Core 3.x) predate the `unknown` member at the head of the manifest file type enum, so their types are all one less than V2+: deps.json is 2, runtimeconfig.json is 3. we were matching on the V2+ value, which silently matched runtimeconfig.json instead, so every .NET Core 3.x single-file app reported its runtimeconfig as the embedded deps.json and its dependencies went unseen. the existing fixture test asserted the buggy output (it expected `runtimeOptions`, which only ever appears in a runtimeconfig). the assertions now pin the framework moniker out of each fixture's real deps.json, so reading the neighboring file can't pass. Signed-off-by: Alex Goodman <wagoodman@users.noreply.github.com> * test(dotnet): drop the 64MB jruby binary from the net8-app fixture the `image-net8-app` fixture wget'd a 64MB jruby release binary at build time to serve as "a PE that is not a .NET binary", which was 64MB of the image's 65MB. every test that loads that image pays for it, in both the dotnet cataloger and the pe package, and it sits in the fixture cache twice. the same jruby binary already has its own fixture in the binary cataloger (`image-jruby`), asserted through the same `pe.Read`, so the coverage is not lost. the negative case here now uses `/app/dotnetapp.exe` -- the native apphost that is already in the image -- which pairs nicely with the single file case, same apphost with the app bundled in and CLR evidence present. also drops a github release download from the fixture build. Signed-off-by: Alex Goodman <wagoodman@users.noreply.github.com> --------- Signed-off-by: Alex Goodman <wagoodman@users.noreply.github.com>
Syft
A CLI tool and Go library for generating a Software Bill of Materials (SBOM) from container images and filesystems. Exceptional for vulnerability detection when used with a scanner like Grype.
Features
- Generates SBOMs for container images, filesystems, archives (see the docs for a full list of supported scan targets)
- Supports dozens of packaging ecosystems (e.g. Alpine (apk), Debian (dpkg), RPM, Go, Python, Java, JavaScript, Ruby, Rust, PHP, .NET, and many more)
- Supports OCI, Docker, Singularity, and more image formats
- Works seamlessly with Grype for vulnerability scanning
- Multiple output formats (CycloneDX, SPDX, Syft JSON, and more) including the ability to convert between SBOM formats
- Create signed SBOM attestations using the in-toto specification
Tip
New to Syft? Check out the Getting Started guide for a walkthrough!
Installation
The quickest way to get up and going:
curl -sSfL https://get.anchore.io/syft | sudo sh -s -- -b /usr/local/bin
Tip
See Installation docs for more ways to get Syft, including Homebrew, Docker, Scoop, Chocolatey, Nix, and more!
The basics
See the packages within a container image or directory:
# container image
syft alpine:latest
# directory
syft ./my-project
To get an SBOM, specify one or more output formats:
# SBOM to stdout
syft <image> -o cyclonedx-json
# Multiple SBOMs to files
syft <image> -o spdx-json=./spdx.json -o cyclonedx-json=./cdx.json
Tip
Check out the Getting Started guide to explore all of the capabilities and features.
Want to know all of the ins-and-outs of Syft? Check out the CLI docs, configuration docs, and JSON schema.
Contributing
We encourage users to help make these tools better by submitting issues when you find a bug or want a new feature. Check out our contributing overview and developer-specific documentation if you are interested in providing code contributions.
Syft development is sponsored by Anchore, and is released under the Apache-2.0 License.
The Syft logo by Anchore is licensed under CC BY 4.0
For commercial support options with Syft or Grype, please contact Anchore.
Come talk to us!
The Syft Team holds regular community meetings online. All are welcome to join to bring topics for discussion.
- Check the calendar for the next meeting date.
- Add items to the agenda (join this group for write access to the agenda)
- See you there!