* ERLang parser support for empty lists
* ERLang add support for single quote strings
* ERLang parser support for comments
---------
Signed-off-by: Laurent Goderre <laurent.goderre@docker.com>
Fixes a bug where previously the haskell cataloger would panic
when parsing a stack.yaml.lock file that had an entry with an empty
hackage string.
Signed-off-by: houdini91 <mdstrauss91@gmail.com>
Signed-off-by: Will Murphy <will.murphy@anchore.com>
Co-authored-by: houdini91 <mdstrauss91@gmail.com>
Previously, pointers to primitive types in config summarization could be
printed literally (like "0x123aefef"). Pull in fangs to get the fix for
this.
Signed-off-by: Will Murphy <will.murphy@anchore.com>
According to maven central, the package called "xalan" should just have
the group ID xalan, but currently syft isn't able to find that.
Signed-off-by: Will Murphy <will.murphy@anchore.com>
Previously, building the index of the filesystem when source was file
would fail if part of the path syft was passed to the file included a
symlinked directory, resulting in cataloging misses.
---------
Signed-off-by: Will Murphy <will.murphy@anchore.com>
Allow existing matcher to match host identifiers longer than 12
characters. The binaries distributed by redis have the version before
payload, so add a matcher for that. Add test fixtures covering these
scenarios.
Signed-off-by: David Dooling <david.dooling@docker.com>
* fix: update parsing logic to remove empty space
* tests: update with test cases provided by community
---------
Signed-off-by: Christopher Phillips <christopher.phillips@anchore.com>
* Add ruby.NewGemSpecCataloger to DirectoryCatalogers.
Signed-off-by: Evan <chaol@vmware.com>
* fixed tests
Signed-off-by: Evan <chaol@vmware.com>
* Addressed review comment
Signed-off-by: Evan <chaol@vmware.com>
* Remove NewInstalledGemSpecCataloger from default dir catalogers
Because the files that the installed gemspec cataloger work off of are a
subset of the files that the more general gemspec cataloger will work
off of, we shouldn't have both of them on by default, since this could
result in finding the same package twice.
Signed-off-by: Will Murphy <will.murphy@anchore.com>
---------
Signed-off-by: Evan <chaol@vmware.com>
Signed-off-by: Will Murphy <will.murphy@anchore.com>
Co-authored-by: Will Murphy <will.murphy@anchore.com>
adds a unique synthetic package to the SBOM output that represents the go compiler when it is detected as a part of a package discovered by the go binary cataloger.
When using an SBOM generated by syft - downstream vulnerability scanners now have the opportunity to detect/report on the PURL/CPEs attached to the new stdlib package.
---------
Signed-off-by: Christopher Phillips <christopher.phillips@anchore.com>
Previously, which PURL was generated depended on the order of key iteration
in maps. Also update an integ test that was apparently only passing because
of the previous issue.
Signed-off-by: Will Murphy <will.murphy@anchore.com>
Now that the test fixture pins to a particular digest, there's no need
for platform specific architecture switches in this test.
Signed-off-by: Will Murphy <will.murphy@anchore.com>
Many of these images have a slightly different sets of packages when the
arm64 variant is pulled, so that leaving this digest unpinned causes the
tests to fail on arm64 hosts. Pin the FROM lines to force stable
platform values regardless of host architecture.
Signed-off-by: Will Murphy <will.murphy@anchore.com>
Previously, there were some data races in syft. Right now, none are
detected, so check for data races on the overall command, and on unit
tests. (Checking for races on integration tests triples the time needed
for those tests, from ~1 minute to ~3 minutes on my workstation, so that
was not done at this time.)
Signed-off-by: Will Murphy <will.murphy@anchore.com>
Otherwise, small renames like 'hudson-war-2.2.1.war' to 'hudson.war', would cause
syft to incorrectly catolog the archive.
Signed-off-by: Will Murphy <will.murphy@anchore.com>
If crypto settings or arch cannot be determined, still attempt to catalog packages from
the build info, rather than panicking.
Signed-off-by: Will Murphy <will.murphy@anchore.com>
A recent update to gopom changed many fields to be omitted when empty,
resulting in a number of nil pointers inside the nested structure of the
pom that previously didn't exist. Defend against these in the search for
the property value.
Signed-off-by: Will Murphy <will.murphy@anchore.com>
This reflect code occasionally throws an obscure panic, but not enough
information is logged before the panic to know why it panicked. Log
enough to tell what property and package are being analyzed when the
panic occurs.
Signed-off-by: Will Murphy <will.murphy@anchore.com>
Separate the logic for CPE and PURL generation.
PURL generation needs a single answer for groupID based on a priority of discovering the field.
CPE generation still uses multiple potential groupID to populate the candidate cpe.
Improve GroupID detection.
Currently syft does not use any hierarchy for GroupID detection and treats all sources as equal.
It treats fields from the manifest file with priority. This change adds a hierarchy to the fields and returns a single answer based on that hierarchy.
---------
Signed-off-by: Christopher Phillips <christopher.phillips@anchore.com>
Signed-off-by: Keith Zantow <kzantow@gmail.com>
Co-authored-by: Keith Zantow <kzantow@gmail.com>
Fixes#931
PR #1948 introduces a new implicit exclusion for binary packages that overlap by file ownership and have certain characteristics:
1) the relationship between packages is OwnershipByFileOverlap
2) the parent package is an "os" package - see changelog for included catalogers
3) the child is a synthetic package generated by the binary cataloger - see changelog for included catalogers
4) the package names are identical
---------
Signed-off-by: Christopher Phillips <christopher.phillips@anchore.com>
* Add opkg info directory and status file to deb cataloger
opkg uses the same or nearly the same metadata and structure as Debian:
**/lib/opkg/status lists status information for all packages
**/lib/opkg/info/opkg.conffiles is a list of configuration files
**/lib/opkg/info/*.list contains files and directories installed by the package
**/lib/opkg/info/*.preinst are scripts to run before installation
**/lib/opkg/info/*.postinst are scripts to run after installation
**/lib/opkg/info/*.postrm are scripts to run after package removal
**/lib/opkg/info/*.control provides package metadata
Signed-off-by: Nicholas R. Smith <nicholas_smith@selinc.com>
---------
Signed-off-by: Nicholas R. Smith <nicholas_smith@selinc.com>
Co-authored-by: Nicholas R. Smith <nicholas_smith@selinc.com>
* fix: default image source name to user input
Signed-off-by: Keith Zantow <kzantow@gmail.com>
* chore: add test
Signed-off-by: Keith Zantow <kzantow@gmail.com>
---------
Signed-off-by: Keith Zantow <kzantow@gmail.com>
* Add support for parsing .NET assemblies
Signed-off-by: Dan Luhring <dluhring@chainguard.dev>
Former-commit-id: 69c33fe4d77357d843c11590f3b07825bc6249ac
* Add dll and exe files
Signed-off-by: Dan Luhring <dluhring@chainguard.dev>
Former-commit-id: b9d204efa6d2ef385b5fbb7a59a3474ecabea641
* Add PE cataloger to directory catalogers
Signed-off-by: Dan Luhring <dluhring@chainguard.dev>
Former-commit-id: 9711c00d9da92e2887e0c1f92edd740ea5345849
* Don't set language to dotnet for PEs
Signed-off-by: Dan Luhring <dluhring@chainguard.dev>
Former-commit-id: 368313fddac9160d8a06a01ebe8c5ac7990232f5
* Fix spelling of cataloger in constructor
Signed-off-by: Dan Luhring <dluhring@chainguard.dev>
Former-commit-id: e42fd77b2f8b6d42e076a84f6cce386861260941
* Adjust which cases in PE parsing return errors
Signed-off-by: Dan Luhring <dluhring@chainguard.dev>
Former-commit-id: 95b25f8fc3a7d4e18fe30e489b09851f316795ff
* remove build binary from branch
Signed-off-by: Alex Goodman <wagoodman@users.noreply.github.com>
Former-commit-id: fa54c0d0aef0998d5520e9f44cae51f5f9cd38a2
* Fix failing CLI tests
Signed-off-by: Dan Luhring <dluhring@chainguard.dev>
---------
Signed-off-by: Dan Luhring <dluhring@chainguard.dev>
Co-authored-by: Alex Goodman <wagoodman@users.noreply.github.com>
* docs: update docs with new docker specific instructions
---------
Signed-off-by: Christopher Phillips <christopher.phillips@anchore.com>
Former-commit-id: c67c76e84df84e3e24aa307637d884ca8b7e3eea
* fix: or-later suffix has been updated to consider deprecated +
If a given license has the suffix "or-later" it previously could have
been considered or represented with a "+". Example "GFDL-1.0-or-later"
could have been represented as "GFDL-1.0+". This PR allows the license
list generation to consider "or-later" as == to "+" when generating
permutations for upgrading deprecated licenses.
---------
Signed-off-by: Christopher Phillips <christopher.phillips@anchore.com>
Add some explanation around why there are different default sets of catalogers for image scans versus directory scans. Hopefully clarify questions related to #1776.
Signed-off-by: Timothy Gerla <tim@gerla.net>
Track a chronicle config file that causes chronicle to bump minor
version instead of major version in response to the "breaking-change"
label for pre-1.0 releases.
Signed-off-by: Will Murphy <will.murphy@anchore.com>
* [wip] try to reflect metadata types... probably wont work
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
* refactor to add unit test to ensure there is coverage in the schema
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
* [wip] generate metadata container
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
* add generation of metadata container struct for JSON schema generation
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
* fix linting
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
* update linter script to account for code generation
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
---------
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
to keep things consistent across the schema we want Locations and URLs to be plural fields now that they are fields on the License struct
---------
Signed-off-by: Christopher Phillips <christopher.phillips@anchore.com>
this PR makes the following changes to update the underlying license model to have more expressive capabilities
it also provides some guarantee's surrounding the license values themselves
- Licenses are updated from string -> pkg.LicenseSet which contain pkg.License with the following fields:
- original `Value` read by syft
- If it's possible to construct licenses will always have a valid SPDX expression for downstream consumption
- the above is run against a generated list of SPDX license ID to try and find the correct ID
- SPDX concluded vs declared is added to the new struct
- URL source for license is added to the new struct
- Location source is added to the new struct to show where the expression was pulled from
If syft is asked to parse an SBOM that was written by a newer version of
syft, emit a warning, since the current version of syft doesn't know about
fields that may be added in the future.
Signed-off-by: Will Murphy <will.murphy@anchore.com>
Add a cataloger that detects installed R packages by looking for DESCRIPTION
files. The base R package is now picked up in coverageImage tests in
test/cli/packages_cmd_test.go, so increment expected package counts for the
tests that use that image.
Signed-off-by: Will Murphy <will.murphy@anchore.com>
Rather than log a warning for every instance of an unknown relationship type,
or similar error, log a count of how many times each of these errors is
raised.
---------
Signed-off-by: Will Murphy <will.murphy@anchore.com>
The tests in test/cli/packages_cmd_test.go are hard to debug when different
packages are found in different environments. For example, CI runs and M1 macs
have been observed to have different package counts. Therefore, if the test is
about to fail, log a sorted list of the packages that were found, so that it is
easy to compare failures of these tests.
Signed-off-by: Will Murphy <will.murphy@anchore.com>
- Create new metadata struct and type for python requirements.
- Update parsing of python requirements to use python requirements metadata.
- Remove extras and url from line. Add them to metadata instead.
- Add unit test to test that extras are removed from package name.
- Update test to look at requirements metadata.
- Will need updated in future to support more than just == for the version constraint.
- Update JSON schema data
Closesanchore/grype#1246Closesanchore/grype#1251
Signed-off-by: Shane Dell <shanedell100@gmail.com>
* Create consul binary classifier
Closes#1590
Signed-off-by: Shane Dell <shanedell100@gmail.com>
* Create test for consul binary classifier
Signed-off-by: Shane Dell <shanedell100@gmail.com>
* Update version for consul. Add note that about consul version matcher is brittle
Signed-off-by: Shane Dell <shanedell100@gmail.com>
---------
Signed-off-by: Shane Dell <shanedell100@gmail.com>
- Update README.md to show that nar is now supported.
- Created a java-archives/example.nar so that the tests wouldn't break.
- Add nar glob and as an option for pkgType.
Closes#1701
Signed-off-by: Shane Dell <shanedell100@gmail.com>
Update the license_list.go to have more permissible inputs for greater SPDXID matching.
EX:
GPL3 gpl3 gpl-3 and GPL-3 can all map to GPL-3.0-only
By moving all strings to lower and removing the "-" we're able to return valid SPDX license ID for a greater diversity of input strings.
---------
Signed-off-by: Christopher Phillips <christopher.phillips@anchore.com>
* add argocd, helm, kustomize and kubectl binary classifiers
* update golang PURL
* address PR faceback about binary/test-fixtures/Makefile
* remove the /v[n] suffix from the PURL in both argocd and helm
---------
Signed-off-by: y12studio <y12studio@gmail.com>
Adding APK OriginPackage CPE candidates to the child package
results in false positives in grype because it can't associate
CPE-based findings to the corresponding OriginPackage APK fixes.
This reverts changing the `upstream` in the PURL for APK packages
as the logic in Grype that uses it expects it to be an APK package
name. This also allows refactoring to unexport and move the APK
CPE candidate generation logic closer to where CPE generation occurs
Signed-off-by: Weston Steimel <weston.steimel@anchore.com>
This fixes some instances where the improved APK CPE generation
logic caused regressions for older alpine package APK metadata.
It now generates multiple "upstream" candidates with both name
and package type which reduces the amount of duplicated code in
the apk cpe gen logic. This also improves the handling of stream
version packages, so now we can correctly identify packages such
as ruby3.2-rexml as the rexml ruby gem.
Signed-off-by: Weston Steimel <weston.steimel@anchore.com>
The apk purl spec allows for vendor-specific namespace. I noticed
in the embedded SBOMs from wolfi that the purls are of the form
`pkg:apk/wolfi/curl@7.83.0-r0?arch=x86`, but the current logic in
syft actually prevents purl generation entirely if the distro isn't
alpine, so this corrects that behaviour.
Signed-off-by: Weston Steimel <weston.steimel@anchore.com>
* refactor: move apk upstream logic to apk metadata
Export the logic for parsing upstream APK package names
so it can be accessed from apk metadata objects directly.
This also tightens the upstream regex pattern as several
edge cases were being missed.
Signed-off-by: Weston Steimel <weston.steimel@anchore.com>
* fix: ensure correct handling for apk packages beginning with digits
Signed-off-by: Weston Steimel <weston.steimel@anchore.com>
* fix: upstream generation for ruby
Signed-off-by: Weston Steimel <weston.steimel@anchore.com>
---------
Signed-off-by: Weston Steimel <weston.steimel@anchore.com>
* replace raw globs with index equivelent operations
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
* add cataloger test for alpm cataloger
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
* fix import sorting for binary cataloger
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
* fix linting for mock resolver
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
* separate portage cataloger parser impl from cataloger
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
* enhance cataloger pkgtest utils to account for resolver responses
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
* add glob-based cataloger tests for alpm cataloger
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
* add glob-based cataloger tests for apkdb cataloger
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
* add glob-based cataloger tests for dpkg cataloger
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
* add glob-based cataloger tests for cpp cataloger
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
* add glob-based cataloger tests for dart cataloger
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
* add glob-based cataloger tests for dotnet cataloger
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
* add glob-based cataloger tests for elixir cataloger
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
* add glob-based cataloger tests for erlang cataloger
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
* add glob-based cataloger tests for golang cataloger
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
* add glob-based cataloger tests for haskell cataloger
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
* add glob-based cataloger tests for java cataloger
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
* add glob-based cataloger tests for javascript cataloger
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
* add glob-based cataloger tests for php cataloger
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
* add glob-based cataloger tests for portage cataloger
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
* add glob-based cataloger tests for python cataloger
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
* add glob-based cataloger tests for rpm cataloger
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
* add glob-based cataloger tests for rust cataloger
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
* add glob-based cataloger tests for sbom cataloger
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
* add glob-based cataloger tests for swift cataloger
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
* allow generic catloger to run all mimetype searches at once
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
* remove stutter from php and javascript cataloger constructors
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
* bump stereoscope
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
* add tests for generic.Search
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
* add exceptions for java archive git ignore entries
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
* enhance basename and extension resolver methods to be variadic
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
* dont allow * prefix on extension searches
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
* add glob-based cataloger tests for ruby cataloger
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
* remove unnecessary string casting
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
* incorporate surfacing of leaf link resolitions from stereoscope results
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
* [wip] switch to stereoscope file metadata
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
* [wip + failing] revert to old globs but keep new resolvers
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
* index files, links, and dirs within the directory resolver
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
* fix several resolver bugs and inconsistencies
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
* move format testutils to internal package
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
* update syft json to account for file type string normalization
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
* split up directory resolver from indexing
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
* update docs to include details about searching
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
* [wip] bump stereoscope to development version
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
* fix linting
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
* adjust symlinks fixture to be fixed to digest
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
* fix all-locations resolver tests
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
* fix test fixture reference
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
* rename file.Type
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
* bump stereoscope
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
* fix PR comment to exclude extra *
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
* bump to dev version of stereoscope
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
* bump to final version of stereoscope
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
* move observing resolver to pkgtest
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
---------
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
* add release trigger
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
* deduplicate version and changelog calls + add gh checks
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
* add more chronicle verbosity, but not when triggering releases
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
* bump chronicle version to get --version-file feature
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
* update bootstrap tool workflow to include glow
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
* add version prefix check on tags in release quality gate
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
---------
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
When base is set, it should appear identically to when we scan the root
filesystem - and as a result, the path should begin with the path
separator.
E.g. when scanning the root `./target/` with the same base,
`target/bin/busybox` should appear in the output as `/bin/busybox`, not
as previously as `bin/busybox`.
Signed-off-by: Justin Chadwell <me@jedevc.com>
* fix: update config struct to not decode password/key
* test: update tests to confirm no secrets in output
Signed-off-by: Christopher Phillips <christopher.phillips@anchore.com>
---------
Signed-off-by: Christopher Phillips <christopher.phillips@anchore.com>
log_crit "uname_os_check '$(uname -s)' got converted to '$os' which is not a GOOS value. Please file bug at https://github.com/client9/shlib"
return1
}
uname_arch_check(){
arch=$(uname_arch)
case"$arch" in
386)return0;;
amd64)return0;;
arm64)return0;;
armv5)return0;;
armv6)return0;;
armv7)return0;;
ppc64)return0;;
ppc64le)return0;;
mips)return0;;
mipsle)return0;;
mips64)return0;;
mips64le)return0;;
s390x)return0;;
amd64p32)return0;;
esac
log_crit "uname_arch_check '$(uname -m)' got converted to '$arch' which is not a GOARCH value. Please file bug report at https://github.com/client9/shlib"
return1
}
untar(){
tarball=$1
case"${tarball}" in
*.tar.gz | *.tgz) tar --no-same-owner -xzf "${tarball}";;
*.tar) tar --no-same-owner -xf "${tarball}";;
*.zip) unzip "${tarball}";;
*)
log_err "untar unknown archive format for ${tarball}"
@@ -6,6 +6,26 @@ In order to test and develop in this repo you will need the following dependenci
- Golang
- docker
- make
- Python (>= 3.9)
### Docker settings for getting started
Make sure you've updated your docker settings so the default docker socket path is available.
Go to:
docker -> settings -> advanced
Make sure:
```
Allow the default Docker socket to be used
```
is checked.
Also double check that the docker context being used is the default context. If it is not, run:
`docker context use default`
After cloning the following step can help you get setup:
1. run `make bootstrap` to download go mod dependencies, create the `/.tmp` dir, and download helper utilities.
@@ -15,43 +35,55 @@ After cloning the following step can help you get setup:
- this command `go run cmd/syft/main.go alpine:latest` will compile and run syft against `alpine:latest`
5. view the README or syft help output for more output options
The main make tasks for common static analysis and testing are `lint`, `lint-fix`, `unit`, `integration`, and `cli`.
The main make tasks for common static analysis and testing are `lint`,`format`,`lint-fix`, `unit`, `integration`, and `cli`.
See `make help` for all the current make tasks.
### Internal Artifactory Settings
**Not always applicable**
Some companies have Artifactory setup internally as a solution for sourcing secure dependencies.
If you're seeing an issue where the unit tests won't run because of the below error then this section might be relevant for your use case.
```
[ERROR] [ERROR] Some problems were encountered while processing the POMs
```
If you're dealing with an issue where the unit tests will not pull/build certain java fixtures check some of these settings:
- a `settings.xml` file should be available to help you communicate with your internal artifactory deployment
- this can be moved to `syft/pkg/cataloger/java/test-fixtures/java-builds/example-jenkins-plugin/` to help build the unit test-fixtures
- you'll also want to modify the `build-example-jenkins-plugin.sh` to use `settings.xml`
For more information on this setup and troubleshooting see [issue 1895](https://github.com/anchore/syft/issues/1895#issuecomment-1610085319)
## Architecture
Syft is used to generate a Software Bill of Materials (SBOM) from different kinds of input.
### Code organization for the cmd package
Syft's entrypoint can be found in the `cmd` package at `cmd/syft/main.go`. `main.go` builds a new syft `cli` via `cli.New()`
and then executes the `cli` via `cli.Execute()`. The `cli` package is responsible for parsing command line arguments,
setting up the application context and configuration, and executing the application. Each of syft's commands
(e.g. `packages`, `attest`, `version`) are implemented as a `cobra.Command` in their respective `<command>.go` files.
They are registered in `syft/cli/commands/go`.
At a high level, this is the package structure of syft:
```
.
└── syft/
├── cli/
│ ├── attest/
│ ├── attest.go
│ ├── commands.go
│ ├── completion.go
│ ├── convert/
│ ├── convert.go
│ ├── eventloop/
│ ├── options/
│ ├── packages/
│ ├── packages.go
│ ├── poweruser/
│ ├── poweruser.go
│ └── version.go
└── main.go
./cmd/syft/
│ ├── cli/
│ │ ├── cli.go // where all commands are wired up
│ │ ├── commands/ // all command implementations
│ │ ├── options/ // all command flags and configuration options
│ │ └── ui/ // all handlers for events that are shown on the UI
│└── main.go // entrypoint for the application
└── syft/ // the "core" syft library
├── format/ // contains code to encode or decode to and from SBOM formats
├── pkg/ // contains code to catalog packages from a source
├── sbom/ // contains the definition of an SBOM
└── source/ // contains code to create a source object for some input type (e.g. container image, directory, etc)
```
#### Execution flow
Syft's core library is implemented in the `syft` package and subpackages, where the major packages are:
- the `syft/source` package produces a `source.Source` object that can be used to catalog a directory, container, and other source types.
- the `syft` package contains a single function that can take a `source.Source` object and catalog it, producing an `sbom.SBOM` object
- the `syft/format` package contains the ability to encode and decode SBOMs to and from different SBOM formats (such as SPDX and CycloneDX)
The `cmd` pacakge at the highest level execution flow wires up [`spf13/cobra`](https://github.com/spf13/cobra) commands for execution in the main application:
```mermaid
sequenceDiagram
participant main as cmd/syft/main
@@ -75,24 +107,7 @@ sequenceDiagram
Note right of cmd: Execute SINGLE command from USER
```
### Code organization for syft library
Syft's core library (see, exported) functionality is implemented in the `syft` package. The `syft` package is responsible for organizing the core
SBOM data model, it's translated output formats, and the core SBOM generation logic.
- analysis creates a static SBOM which can be encoded and decoded
- format objects, should strive to not add or enrich data in encoding that could otherwise be done during analysis
- package catalogers and their organization can be viewed/added to the `syft/pkg/cataloger` package
- file catalogers and their organization can be viewed/added to the `syft/file` package
- The source package provides an abstraction to allow a user to loosely define a data source that can be cataloged
#### Code example of syft as a library
Here is a gist of using syft as a library to generate a SBOM for a docker image: [link](https://gist.github.com/wagoodman/57ed59a6d57600c23913071b8470175b).
The execution flow for the example is detailed below.
#### Execution flow examples for the syft library
The `packages` command uses the core library to generate an SBOM for the given user input:
```mermaid
sequenceDiagram
participant source as source.New(ubuntu:latest)
@@ -111,51 +126,104 @@ sequenceDiagram
Note right of catalog: cataloger configuration is done based on src
```
Additionally, here is a [gist of using syft as a library](https://gist.github.com/spiffcs/3027638b7ba904d07e482a712bc00d3d) to generate a SBOM for a docker image.
### `pkg.Package` object
The `pkg.Package` object is a core data structure that represents a software package. Fields like `name` and `version` probably don't need
a detailed explanation, but some of the other fields are worth a quick overview:
-`FoundBy`: the name of the cataloger that discovered this package (e.g. `python-pip-cataloger`).
-`Locations`: these are the set of paths and layer ids that were parsed to discover this package (e.g. `python-pip-cataloger`).
-`Language`: the language of the package (e.g. `python`).
-`Type`: this is a high-level categorization of the ecosystem the package resides in. For instance, even if the package is a egg, wheel, or requirements.txt reference, it is still logically a "python" package. Not all package types align with a language (e.g. `rpm`) but it is common.
-`Metadata`: specialized data for specific location(s) parsed. We should try and raise up as much raw information that seems useful. As a rule of thumb the object here should be as flat as possible and use the raw names and values from the underlying source material parsed.
When `pkg.Package` is serialized an additional `MetadataType` is shown. This is a label that helps consumers understand the datashape of the `Metadata` field.
By convention the `MetadataType` value should follow these rules of thumb:
- Only use lowercase letters, numbers, and hyphens. Use hyphens to separate words.
- **Try to anchor the name in the ecosystem, language, or packaging tooling it belongs to**. For a package manager for a language ecosystem the language, framework or runtime should be used as a prefix. For instance `pubspec-lock` is an OK name, but `dart-pubspec-lock` is better. For an OS package manager this is not necessary (e.g. `apk-db-entry` is a good name, but `alpine-apk-db-entry` is not since `alpine` and the `a` in `apk` is redundant).
- **Be as specific as possible to what the data represents**. For instance `ruby-gem` is NOT a good `MetadataType` value, but `ruby-gemspec` is. Why? Ruby gem information can come from a gemspec file or a Gemfile.lock, which are very different. The latter name provides more context as to what to expect.
- **Should describe WHAT the data is, NOT HOW it's used**. For instance `r-description-installed-file` is NOT a good `MetadataType` value since it's trying to convey that we use the DESCRIPTION file in the R ecosystem to detect installed packages. Instead simply describe what the DESCRIPTION file is itself without context of how it's used: `r-description`.
- **Use the `lock` suffix** to distinct between manifest files that loosely describe package version requirements vs files that strongly specify one and only one version of a package ("lock" files). These should only be used with respect to package managers that have the guide and lock distinction, but would not be appropriate otherwise (e.g. `rpm` does not have a guide vs lock, so `lock` should NOT be used to describe a db entry).
- **Use the `archive` suffix to indicate a package archive** (e.g. rpm file, apk file, etc) that describes the contents of the package. For example an RPM file that was cataloged would have a `rpm-archive` metadata type (not to be confused with an RPM DB record entry which would be `rpm-db-entry`).
- **Use the `entry` suffix** to indicate information about a package that was found as a single entry within file that has multiple package entries. If the entry was found within a DB or a flat-file store for an OS package manager, you should use `db-entry`.
- **Should NOT contain the phrase `package`**, though exceptions are allowed (say if the canonical name literally has the phrase package in it).
- **Should NOT contain have a `file` suffix** unless the canonical name has the term "file", such as a `pipfile` or `gemfile`. An example of a bad name for this rule is`ruby-gemspec-file`; a better name would be `ruby-gemspec`.
- **Should NOT contain the exact filename+extensions**. For instance `pipfile.lock` shouldn't really be in the name, instead try and describe what the file is: `python-pipfile-lock` (but shouldn't this be `python-pip-lock` you might ask? No, since the `pip` package manger is not related to the `pipfile` project).
- **Should NOT contain the phrase `metadata`**, unless the canonical name has this term.
- **Should represent a single use case**. For example, trying to describe Hackage metadata with a single `HackageMetadata` struct (and thus `MetadataType`) is not allowed since it represents 3 mutually exclusive use cases: representing a `stack.yaml`, `stack.lock`, or `cabal.project` file. Instead, each of these should have their own struct types and `MetadataType` values.
There are other cases that are not covered by these rules... and that's ok! The goal is to provide a consistent naming scheme that is easy to understand and use when it's applicable. If the rules do not exactly apply in your situation then just use your best judgement (or amend these rules as needed whe new common cases come up).
What if the underlying parsed data represents multiple files? There are two approaches to this:
- use the primary file to represent all the data. For instance, though the `dpkg-cataloger` looks at multiple files to get all information about a package, it's the `status` file that gets represented.
- nest each individual file's data under the `Metadata` field. For instance, the `java-archive-cataloger` may find information from on or all of the files: `pom.xml`, `pom.properties`, and `MANIFEST.MF`. However, the metadata is simply `java-metadata' with each possibility as a nested optional field.
### Syft Catalogers
##### Summary
Catalogers are the way in which syft is able to identify and construct packages given a set a targeted list of files.
For example, a cataloger can ask syft for all `package-lock.json` files in order to parse and raise up javascript packages
(see [how file globs](https://github.com/anchore/syft/tree/v0.70.0/syft/pkg/cataloger/javascript/cataloger.go#L16-L21) and
[file parser functions](https://github.com/anchore/syft/tree/v0.70.0/syft/pkg/cataloger/javascript/cataloger.go#L16-L21) are used
for a quick example).
Catalogers are the way in which syft is able to identify and construct packages given some amount of source metadata.
For example, Syft can locate and process `package-lock.json` files when performing filesystem scans.
See: [how to specify file globs](https://github.com/anchore/syft/blob/main/syft/pkg/cataloger/javascript/cataloger.go#L16-L21)
and an implementation of the [package-lock.json parser](https://github.com/anchore/syft/blob/main/syft/pkg/cataloger/javascript/cataloger.go#L16-L21) fora quick review.
From a high level catalogers have the following properties:
- _They are independent from one another_. The java cataloger has no idea of the processes, assumptions, or results of the python cataloger, for example.
- _They do not know what source is being analyzed_. Are we analyzing a local directory? an image? if so, the squashed representation or all layers? The catalogers do not know the answers to these questions. Only that there is an interface to query for file paths and contents from an underlying "source" being scanned.
- _Packages created by the cataloger should not be mutated after they are created_. There is one exception made for adding CPEs to a package after the cataloging phase, but that will most likely be moved back into the cataloger in the future.
Cataloger names should be unique and named with the following rules of thumb in mind:
- Must end with `-cataloger`
- Use lowercase letters, numbers, and hyphens only
- Use hyphens to separate words
- Catalogers for language ecosystems should start with the language name (e.g. `python-` for a cataloger that raises up python packages)
- Distinct between when the cataloger is searching for evidence of installed packages vs declared packages. For example, there are currently two different gemspec-based catalogers, the `ruby-gemspec-cataloger` and `ruby-installed-gemspec-cataloger`, where the latter requires that the gemspec is found within a `specifications` directory (which means it was installed, not just at the root of a source repo).
#### Building a new Cataloger
Catalogers must fulfill the interface [found here](https://github.com/anchore/syft/blob/main/syft/pkg/cataloger.go).
This means that when building a new cataloger, the new struct must implement both method signatures of `Catalog` and `Name`.
Catalogers must fulfill the [`pkg.Cataloger` interface](https://github.com/anchore/syft/tree/v0.70.0/syft/pkg/cataloger.go) in order to add packages to the SBOM.
All catalogers should be added to:
- the [global list of catalogers](https://github.com/anchore/syft/blob/9995950c70e849f9921919faffbfcf46401f71f3/syft/pkg/cataloger/cataloger.go#L92-L125)
- at least one source-specific list, today the two lists are [directory catalogers and image catalogers](https://github.com/anchore/syft/blob/9995950c70e849f9921919faffbfcf46401f71f3/syft/pkg/cataloger/cataloger.go#L39-L89)
A top level view of the functions that construct all the catalogers can be found [here](https://github.com/anchore/syft/blob/main/syft/pkg/cataloger/cataloger.go).
When an author has finished writing a new cataloger this is the spot to plug in the new catalog constructor.
For reference, catalogers are [invoked within syft](https://github.com/anchore/syft/tree/v0.70.0/syft/pkg/cataloger/catalog.go#L41-L100) one after the other, and can be invoked in parallel.
For a top level view of how the catalogers are used see [this function](https://github.com/anchore/syft/blob/main/syft/pkg/cataloger/catalog.go#L41-L100) as a reference. It ranges over all catalogers passed as an argument and invokes the `Catalog` method:
`generic.NewCataloger` is an abstraction syft used to make writing common components easier (see the [apkdb cataloger](https://github.com/anchore/syft/tree/v0.70.0/syft/pkg/cataloger/apkdb/cataloger.go) for example usage).
It takes the following information as input:
- A `catalogerName` to identify the cataloger uniquely among all other catalogers.
- Pairs of file globs as well as parser functions to parse those files. These parser functions return a slice of [`pkg.Package`](https://github.com/anchore/syft/blob/9995950c70e849f9921919faffbfcf46401f71f3/syft/pkg/package.go#L19) as well as a slice of [`artifact.Relationship`](https://github.com/anchore/syft/blob/9995950c70e849f9921919faffbfcf46401f71f3/syft/artifact/relationship.go#L31) to describe how the returned packages are related. See this [the apkdb cataloger parser function](https://github.com/anchore/syft/tree/v0.70.0/syft/pkg/cataloger/apkdb/parse_apk_db.go#L22-L102) as an example.
Each cataloger has its own `Catalog` method, but this does not mean that they are all vastly different.
Take a look at the `apkdb` cataloger for alpine to see how it [constructs a generic.NewCataloger](https://github.com/anchore/syft/blob/main/syft/pkg/cataloger/apkdb/cataloger.go).
`generic.NewCataloger` is an abstraction syft uses to make writing common components easier. First, it takes the `catalogerName` to identify the cataloger.
On the other side of the call it uses two key pieces which inform the cataloger how to identify and return packages, the `globPatterns` and the `parseFunction`:
- The first piece is a `parseByGlob` matching pattern used to identify the files that contain the package metadata.
See [here for the APK example](https://github.com/anchore/syft/blob/main/syft/pkg/apk_metadata.go#L16-L41).
- The other is a `parseFunction` which informs the cataloger what to do when it has found one of the above matches files.
See this [link for an example](https://github.com/anchore/syft/blob/main/syft/pkg/cataloger/apkdb/parse_apk_db.go#L22-L102).
If you're unsure about using the `Generic Cataloger` and think the use case being filled requires something more custom
just file an issue or ask in our slack, and we'd be more than happy to help on the design.
Identified packages share a common struct so be sure that when the new cataloger is constructing a new package it is using the [`Package` struct](https://github.com/anchore/syft/blob/main/syft/pkg/package.go#L16-L31).
Metadata Note: Identified packages are also assigned specific metadata that can be unique to their environment.
See [this folder](https://github.com/anchore/syft/tree/main/syft/pkg) for examples of the different metadata types.
Identified packages share a common `pkg.Package` struct so be sure that when the new cataloger is constructing a new package it is using the [`Package` struct](https://github.com/anchore/syft/tree/v0.70.0/syft/pkg/package.go#L16-L31).
If you want to return more information than what is available on the `pkg.Package` struct then you can do so in the `pkg.Package.Metadata` section of the struct, which is unique for each [`pkg.Type`](https://github.com/anchore/syft/blob/v0.70.0/syft/pkg/type.go).
See [the `pkg` package](https://github.com/anchore/syft/tree/v0.70.0/syft/pkg) for examples of the different metadata types that are supported today.
These are plugged into the `MetadataType` and `Metadata` fields in the above struct. `MetadataType` informs which type is being used. `Metadata` is an interface converted to that type.
Finally, here is an example of where the package construction is done in the apk cataloger. The first link is where `newPackage` is called in the `parseFunction`. The second link shows the package construction:
- [Call for new package](https://github.com/anchore/syft/blob/6a7d6e6071829c7ce2943266c0e187b27c0b325c/syft/pkg/cataloger/apkdb/parse_apk_db.go#L96-L99)
Finally, here is an example of where the package construction is done within the apk cataloger:
- [Calling the APK package constructor from the parser function](https://github.com/anchore/syft/blob/v0.70.0/syft/pkg/cataloger/apkdb/parse_apk_db.go#L106)
If you have more questions about implementing a cataloger or questions about one you might be currently working
always feel free to file an issue or reach out to us [on slack](https://anchore.com/slack).
Interested in building a new cataloger? Checkout the [list of issues with the `new-cataloger` label](https://github.com/anchore/syft/issues?q=is%3Aopen+is%3Aissue+label%3Anew-cataloger+no%3Aassignee)!
If you have questions about implementing a cataloger feel free to file an issue or reach out to us [on slack](https://anchore.com/slack)!
#### Searching for files
All catalogers are provided an instance of the [`file.Resolver`](https://github.com/anchore/syft/blob/v0.70.0/syft/source/file_resolver.go#L8) to interface with the image and search for files. The implementations for these
abstractions leverage [`stereoscope`](https://github.com/anchore/stereoscope) in order to perform searching. Here is a
rough outline how that works:
1. a stereoscope `file.Index` is searched based on the input given (a path, glob, or MIME type). The index is relatively fast to search, but requires results to be filtered down to the files that exist in the specific layer(s) of interest. This is done automatically by the `filetree.Searcher` abstraction. This abstraction will fallback to searching directly against the raw `filetree.FileTree` if the index does not contain the file(s) of interest. Note: the `filetree.Searcher` is used by the `file.Resolver` abstraction.
2. Once the set of files are returned from the `filetree.Searcher` the results are filtered down further to return the most unique file results. For example, you may have requested for files by a glob that returns multiple results. These results are filtered down to deduplicate by real files, so if a result contains two references to the same file, say one accessed via symlink and one accessed via the real path, then the real path reference is returned and the symlink reference is filtered out. If both were accessed by symlink then the first (by lexical order) is returned. This is done automatically by the `file.Resolver` abstraction.
3. By the time results reach the `pkg.Cataloger` you are guaranteed to have a set of unique files that exist in the layer(s) of interest (relative to what the resolver supports).
# the only difference between goimports and gosimports is that gosimports removes extra whitespace between import blocks (see https://github.com/golang/go/issues/20818)
GOBIN="$(realpath $(TEMP_DIR))" go install github.com/rinchsan/gosimports/cmd/gosimports@$(GOSIMPORTS_VERSION)
GOBIN="$(realpath $(TEMP_DIR))" go install github.com/neilpa/yajsv@$(YAJSV_VERSION)
GOBIN="$(realpath $(TEMP_DIR))" go install github.com/sigstore/cosign/cmd/cosign@$(COSIGN_VERSION)
# note: we need to assume that binny and task have not already been installed
.PHONY:task
$(TASK) task:$(BINNY)
@$(BINNY) install task -q
.PHONY:bootstrap-go
bootstrap-go:
.PHONY:ci-bootstrap-go
ci-bootstrap-go:
go mod download
$(TEMP_DIR):
mkdir -p $(TEMP_DIR)
# this is a bootstrapping catch-all, where if the target doesn't exist, we'll ensure the tools are installed and then try again
@@ -42,15 +42,18 @@ For commercial support options with Syft or Grype, please [contact Anchore](http
- Erlang (rebar3)
- Go (go.mod, Go binaries)
- Haskell (cabal, stack)
- Java (jar, ear, war, par, sar, native-image)
- Java (jar, ear, war, par, sar, nar, native-image)
- JavaScript (npm, yarn)
- Jenkins Plugins (jpi, hpi)
- Linux kernel archives (vmlinz)
- Linux kernel modules (ko)
- Nix (outputs in /nix/store)
- PHP (composer)
- Python (wheel, egg, poetry, requirements.txt)
- Red Hat (rpm)
- Ruby (gem)
- Rust (cargo.lock)
- Swift (cocoapods)
- Swift (cocoapods, swift-package-manager)
## Installation
@@ -75,6 +78,12 @@ The chocolatey distribution of syft is community maintained and not distributed
chocoinstallsyft-y
```
### Scoop
```powershell
scoopinstallsyft
```
### Homebrew
```bash
brew install syft
@@ -100,23 +109,21 @@ nix-shell -p syft
To generate an SBOM for a container image:
```
```bash
syft <image>
```
The above output includes only software that is visible in the container (i.e., the squashed representation of the image). To include software from all image layers in the SBOM, regardless of its presence in the final image, provide `--scope all-layers`:
```
```bash
syft <image> --scope all-layers
```
### Supported sources
Syft can generate an SBOM from a variety of sources:
## Supported sources
Syft can generate a SBOM from a variety of sources:
```
```bash
# catalog a container image archive (from the result of `docker image save ...`, `podman save ...`, or `skopeo copy` commands)
syft path/to/image.tar
@@ -132,6 +139,7 @@ Sources can be explicitly provided with a scheme:
```
docker:yourrepo/yourimage:tag use images from the Docker daemon
podman:yourrepo/yourimage:tag use images from the Podman daemon
containerd:yourrepo/yourimage:tag use images from the Containerd daemon
docker-archive:path/to/yourimage.tar use a tarball from disk for archives created from "docker save"
oci-archive:path/to/yourimage.tar use a tarball from disk for OCI archives (from Skopeo or otherwise)
oci-dir:path/to/yourimage read directly from a path on disk for OCI layout directories (from Skopeo or otherwise)
@@ -141,46 +149,120 @@ file:path/to/yourproject/file read directly from a path on disk (any
registry:yourrepo/yourimage:tag pull image directly from a registry (no container runtime required)
```
#### Default Cataloger Configuration by scan type
If an image source is not provided and cannot be detected from the given reference it is assumed the image should be pulled from the Docker daemon.
If docker is not present, then the Podman daemon is attempted next, followed by reaching out directly to the image registry last.
##### Image Scanning:
- alpmdb
- rpmdb
- dpkgdb
- apkdb
- portage
- ruby-gemspec
- python-package
- php-composer-installed Cataloger
- javascript-package
- java
- go-module-binary
- dotnet-deps
##### Directory Scanning:
- alpmdb
- apkdb
- dpkgdb
- portage
- rpmdb
- ruby-gemfile
-python-index
-python-package
-php-composer-lock
- javascript-lock
- java
- java-pom
- go-module-binary
- go-mod-file
- rust-cargo-lock
- dartlang-lock
- dotnet-deps
- cocoapods
- conan
- hackage
This default behavior can be overridden with the `default-image-pull-source` configuration option (See [Configuration](https://github.com/anchore/syft#configuration) for more details).
### File selection
By default, Syft will catalog file details and digests for files that are owned by discovered packages. You can change this behavior by using the `SYFT_FILE_METADATA_SELECTION` environment variable or the `file.metadata.selection` configuration option. The options are:
-`all`: capture all files from the search space
-`owned-by-package`: capture only files owned by packages (default)
-`none`: disable capturing any file information
### Package cataloger selection
#### Concepts
> [!IMPORTANT]
> Syft uses a different set of catalogers by default when scanning files directly than it does when scanning images
The catalogers for an image scan assumes that package installation steps have already been completed. For example, Syft will identify Python packages that have egg or wheel metadata files under a `site-packages` directory, since this is how the canonical tooling `pip` installs python packages.
The catalogers for a directory scan will look for installed software as well as declared dependencies that are not necessarily installed. For example, dependencies listed in a Python `requirements.txt`.
This default set of catalogers being dynamic is critical as this allows Syft to be used in a variety of contexts while still generating accurate SBOMs.
Overriding the set of default catalogers is not recommended for most purposes, however, is possible if needed.
Catalogers can be referenced in two different ways:
- *by name*: the exact cataloger name (e.g. `java-pom-cataloger` or `java-archive-cataloger`)
- *by tag*: a tag that is associated with a cataloger (e.g. `java`)
Syft can take lists of references on the CLI or in the application configuration to define which catalogers to use.
You can **set** the list of catalogers explicitly to use with the `--override-default-catalogers` CLI flag, accepting a comma-separated list of cataloger names or tags.
You can also **add** to, **remove** from, or **sub-select** catalogers to use within the default set of catalogers by using the `--select-catalogers` CLI flag.
- To **sub-select** catalogers simply provide a tag (e.g. `--select-catalogers TAG`). Catalogers will always be selected from the default set of catalogers (e.g. `--select-catalogers java,go` will select all the `java` catalogers in the default set and all the `go` catalogers in the default set).
- To **add** a cataloger prefix the cataloger name with `+` (e.g. `--select-catalogers +NAME`). Added catalogers will _always be added_ regardless of removals, filtering, or other defaults.
- To **remove** a cataloger prefix the cataloger name or tag with `-` (e.g. `--select-catalogers -NAME_OR_TAG`). Catalogers are removed from the set of default catalogers after processing any sub-selections.
These rules and the dynamic default cataloger sets approximates to the following logic:
```
image_catalogers = all_catalogers AND catalogers_tagged("image")
directory_catalogers = all_catalogers AND catalogers_tagged("directory")
default_catalogers = image_catalogers OR directory_catalogers
sub_selected_catalogers = default_catalogers INTERSECT catalogers_tagged(TAG) [ UNION sub_selected_catalogers ... ]
base_catalogers = default_catalogers OR sub_selected_catalogers
final_set = (base_catalogers SUBTRACT removed_catalogers) UNION added_catalogers
```
#### Examples
Only scan for python related packages with catalogers appropriate for the source type (image or directory):
-`json`: Use this to get as much information out of Syft as possible!
-`text`: A row-oriented, human-and-machine-friendly output.
-`syft-json`: Use this to get as much information out of Syft as possible!
-`syft-text`: A row-oriented, human-and-machine-friendly output.
-`cyclonedx-xml`: A XML report conforming to the [CycloneDX 1.4 specification](https://cyclonedx.org/specification/overview/).
-`cyclonedx-json`: A JSON report conforming to the [CycloneDX 1.4 specification](https://cyclonedx.org/specification/overview/).
-`spdx-tag-value`: A tag-value formatted report conforming to the [SPDX 2.2 specification](https://spdx.github.io/spdx-spec/).
-`spdx-json`: A JSON report conforming to the [SPDX 2.2 JSON Schema](https://github.com/spdx/spdx-spec/blob/v2.2/schemas/spdx-schema.json).
-`github`: A JSON report conforming to GitHub's dependency snapshot format.
-`table`: A columnar summary (default).
-`spdx-tag-value`: A tag-value formatted report conforming to the [SPDX 2.3 specification](https://spdx.github.io/spdx-spec/v2.3/).
-`spdx-tag-value@2.2`: A tag-value formatted report conforming to the [SPDX 2.2 specification](https://spdx.github.io/spdx-spec/v2.2.2/).
-`spdx-json`: A JSON report conforming to the [SPDX 2.3 JSON Schema](https://github.com/spdx/spdx-spec/blob/v2.3/schemas/spdx-schema.json).
-`spdx-json@2.2`: A JSON report conforming to the [SPDX 2.2 JSON Schema](https://github.com/spdx/spdx-spec/blob/v2.2/schemas/spdx-schema.json).
-`github-json`: A JSON report conforming to GitHub's dependency snapshot format.
-`syft-table`: A columnar summary (default).
-`template`: Lets the user specify the output format. See ["Using templates"](#using-templates) below.
## Using templates
@@ -229,7 +313,7 @@ Syft lets you define custom output formats, using [Go templates](https://pkg.go.
- Specify the path to the template file (`-t ./path/to/custom.template`).
- Syft's template processing uses the same data models as the `json` output format — so if you're wondering what data is available as you author a template, you can use the output from `syft <image> -o json` as a reference.
- Syft's template processing uses the same data models as the `syft-json` output format — so if you're wondering what data is available as you author a template, you can use the output from `syft <image> -o syft-json` as a reference.
**Example:** You could make Syft output data in CSV format by writing a Go template that renders CSV data and then running `syft <image> -o template -t ~/path/to/csv.tmpl`.
@@ -252,13 +336,15 @@ Which would produce output like:
Syft also includes a vast array of utility templating functions from [sprig](http://masterminds.github.io/sprig/) apart from the default Golang [text/template](https://pkg.go.dev/text/template#hdr-Functions) to allow users to customize the output format.
Lastly, Syft has custom templating functions defined in `./syft/format/template/encoder.go` to help parse the passed-in JSON structs.
## Multiple outputs
Syft can also output _multiple_ files in differing formats by appending
`=<file>` to the option, for example to output Syft JSON and SPDX JSON:
This feature is experimental and data might be lost when converting formats. Packages are the main SBOM component easily transferable across formats, whereas files and relationships, as well as other information Syft doesn't support, are more likely to be lost.
We support formats with wide community usage AND good encode/decode support by Syft. The supported formats are:
attestExample=`{{.appName}}{{.command}} --output [FORMAT] alpine:latest defaults to using images from a Docker daemon. If Docker is not present, the image is pulled directly from the registry
Short:"Generate an SBOM as an attestation for the given [SOURCE] container image",
Long:"Generate a packaged-based Software Bill Of Materials (SBOM) from a container image as the predicate of an in-toto attestation that will be uploaded to the image registry",
Short:"Generate an SBOM as an attestation for the given [SOURCE] container image",
Long:"Generate a packaged-based Software Bill Of Materials (SBOM) from a container image as the predicate of an in-toto attestation that will be uploaded to the image registry",
Long:"[Experimental] Convert SBOM files to, and from, SPDX, CycloneDX and Syft's format. For more info about data loss between formats see https://github.com/anchore/syft#format-conversion-experimental",
err=multierror.Append(err,task.ErrInvalidExpression{Expression:"bar",Operation:task.SubSelectOperation,Err:errors.New("explanation")})// this is what makes this test different...
returnfmt.Errorf("unable to read config file during validations %q: %w",o.Config.ConfigFile,err)
}
varlegacylegacyConfig
iferr:=yaml.Unmarshal(by,&legacy);err!=nil{
returnfmt.Errorf("unable to parse config file during validations %q: %w",o.Config.ConfigFile,err)
}
iflegacy.DefaultImagePullSource!=nil{
returnfmt.Errorf("the config file option 'default-image-pull-source' has been removed, please use 'source.image.default-pull-source' instead")
}
iflegacy.ExcludeBinaryOverlapByOwnership!=nil{
returnfmt.Errorf("the config file option 'exclude-binary-overlap-by-ownership' has been removed, please use 'relationships.exclude-binary-packages-with-file-ownership-overlap' instead")
}
iflegacy.BasePath!=nil{
returnfmt.Errorf("the config file option 'base-path' has been removed, please use 'source.base-path' instead")
response:"this is really long this is really long this is really long this is really long this is really long this is really long this is really long this is really long ",
code:200,
expected:nil,
err:true,
name:"too long",
response:"this is really long this is really long this is really long this is really long this is really long this is really long this is really long this is really long ",
Long:"[Experimental] Convert SBOM files to, and from, SPDX, CycloneDX and Syft's format. For more info about data loss between formats see https://github.com/anchore/syft#format-conversion-experimental",
descriptions.Add(&r.PackageFileOwnership,"include package-to-file relationships that indicate which files are owned by which packages.")
descriptions.Add(&r.PackageFileOwnershipOverlap,"include package-to-package relationships that indicate one package is owned by another due to files claimed to be owned by one package are also evidence of another package's existence.")
CheckForAppUpdatebool`yaml:"check-for-app-update" json:"check-for-app-update" mapstructure:"check-for-app-update"`// whether to check for an application update on start up or not
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.