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>
* source: avoid second-step of symlink resolution in directory resolver
We can use the already existing file tree to peform symlink resolution
for FilesByPath, instead of traversing the symlinks again.
This moves all of the symlink logic into the indexing code, and then we
can rely on syft's resolution algorithm over the index in this part of
the codebase.
Signed-off-by: Justin Chadwell <me@jedevc.com>
* source: add base parameter to directory resolver
The new base parameter is an optional parameter for the directory
resolver that resolves all symlinks relative to this root. There are two
intended use cases:
- base = "/". The previous behavior, symlinks are resolved relative to
the root filesystem.
- base = path. Symlinks are resolved relative to the target filesystem,
allowing correct behavior when scanning unpacked container filesystems
on disk.
Signed-off-by: Justin Chadwell <me@jedevc.com>
* source: add tests for new base parameter
Signed-off-by: Justin Chadwell <me@jedevc.com>
---------
Signed-off-by: Justin Chadwell <me@jedevc.com>
* fix AssertEncoderAgainstGoldenSnapshot calls to conditionally update
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
* chore: redact schema versions from syftjson comparison
Signed-off-by: Keith Zantow <kzantow@gmail.com>
* chore: does not need a multiline expression
Signed-off-by: Keith Zantow <kzantow@gmail.com>
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
Signed-off-by: Keith Zantow <kzantow@gmail.com>
Co-authored-by: Keith Zantow <kzantow@gmail.com>
* feat: prefer known CPE vendors over other candidates
All ASF projects will be under the `apache` vendor in CPE, and
indeed this is already one of the candidates, but the logic
for selecting the 'most specific' CPE string would select for
example `apache_software_foundation` or `commons-text`.
This is not necessarily 'wrong' in the CPE candidate selection
logic: there is no way to reliably determine the right candidate.
I think it makes sense to use specific data around the vendor
candidate generation, somewhat similar to
'defaultCandidateAdditions'.
Unfortunately there are still a few CVE's for old (pre-5.x,
long unsupported) tomcat versions that are actually tagged with
`apache_software_foundation`, but I'm not sure those are worth
spending time on.
Signed-off-by: Arnout Engelen <arnout@bzzt.net>
* chore: swap out array of vendors for set data structure
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
Signed-off-by: Arnout Engelen <arnout@bzzt.net>
Signed-off-by: Alex Goodman <alex.goodman@anchore.com>
Co-authored-by: Alex Goodman <alex.goodman@anchore.com>
The original fix b125ea83ba didn't catch
all the excessive warnings, it seems like getArches can also be called
on binaries that aren't neccessarily go binaries, so the messages from
this should also be Trace instead of Warn.
Signed-off-by: Justin Chadwell <me@jedevc.com>
This PR adds support for npm lockfile version 3, which drops the
"dependencies" key and uses "packages" instead. I've refactored the
lockfile parser to make the distinction between the versions explicit
rather than the implicit behaviour before. It _might_ be worth splitting
into separate files at some point, but the logic is so minimal that I
haven't done it.
Fixes#1203
Signed-off-by: Rob Cresswell <robcresswell@users.noreply.github.com>
2022-11-18 12:41:31 -05:00
1440 changed files with 556655 additions and 37573 deletions
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}"
If you are looking to contribute to this project and want to open a GitHub pull request ("PR"), there are a few guidelines of what we are looking for in patches. Make sure you go through this document and ensure that your code proposal is aligned.
@@ -10,7 +10,7 @@ Before you can contribute to Syft, you need to configure your development enviro
You will need to install Go. The version on https://go.dev works best, using the system golang doesn't always work the way you might expect.
At the time of writing, Go 1.19 does not work correctly with Syft. Please use Go 1.18 for now.
Refer to the go.mod file in the root of this repo for the recommended version of Go to install.
You will also need Docker. There's no reason the system packages shouldn't work, but we used the official Docker package. You can find instructions for installing Docker in Debian [here](https://docs.docker.com/engine/install/debian/).
@@ -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,63 +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
#### Make output
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.
```
all Run all linux-based checks (linting, license check, unit, integration, and linux compare tests)
benchmark Run benchmark tests and compare against the baseline (if available)
bootstrap Download and install all tooling dependencies (+ prep tooling in the ./tmp dir)
build Build release snapshot binaries and packages
check-licenses Ensure transitive dependencies are compliant with the current license policy
clean-test-image-cache Clean test image cache
clean Remove previous builds, result reports, and test cache
cli Run CLI tests
compare-linux Run compare tests on build snapshot binaries and packages (Linux)
compare-mac Run compare tests on build snapshot binaries and packages (Mac)
generate-json-schema Generate a new json schema
generate-license-list Generate an updated spdx license list
help Display this help
integration Run integration tests
lint-fix Auto-format all source code + run golangci lint fixers
lint Run gofmt + golangci lint checks
show-test-image-cache Show all docker and image tar cache
show-test-snapshots Show all test snapshots
snapshot-with-signing Build snapshot release binaries and packages (with dummy signing)
test Run all tests (currently unit, integration, linux compare, and cli tests)
unit Run unit tests (with coverage)
[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
@@ -95,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.
#### Organization and design notes for the syft library
- 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
- Logging Abstraction ...
#### Code example of syft as a library
Here is a gist of using syft as a library to generate a SBOM from 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)
@@ -131,8 +126,105 @@ 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
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).
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 [`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)
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.
`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.
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 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)
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 $(TEMPDIR))" go install github.com/rinchsan/gosimports/cmd/gosimports@$(GOSIMPORTS_VERSION)
GOBIN="$(realpath $(TEMPDIR))" go install github.com/neilpa/yajsv@$(YAJSV_VERSION)
GOBIN="$(realpath $(TEMPDIR))" go install github.com/sigstore/cosign/cmd/cosign@$(COSIGN_VERSION)
.PHONY:bootstrap-go
bootstrap-go:
.PHONY:ci-bootstrap-go
ci-bootstrap-go:
go mod download
.PHONY:bootstrap
bootstrap:$(RESULTSDIR)bootstrap-gobootstrap-tools## Download and install all tooling dependencies (+ prep tooling in the ./tmp dir)
$(call title,Bootstrapping dependencies)
# this is a bootstrapping catch-all, where if the target doesn't exist, we'll ensure the tools are installed and then try again
@@ -38,17 +38,22 @@ For commercial support options with Syft or Grype, please [contact Anchore](http
- Debian (dpkg)
- Dotnet (deps.json)
- Objective-C (cocoapods)
- Elixir (mix)
- Erlang (rebar3)
- Go (go.mod, Go binaries)
- Haskell (cabal, stack)
- Java (jar, ear, war, par, sar)
- 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
@@ -73,15 +78,20 @@ The chocolatey distribution of syft is community maintained and not distributed
chocoinstallsyft-y
```
### Scoop
```powershell
scoopinstallsyft
```
### Homebrew
```bash
brew tap anchore/syft
brew install syft
```
### Nix
**Note**: Nix packaging of Syft is [community maintained](https://github.com/NixOS/nixpkgs/blob/master/pkgs/tools/admin/syft/default.nix). Syft is currently only in the [unstable channel](https://nixos.wiki/wiki/Nix_channels#The_official_channels) awaiting the`22.05` release
**Note**: Nix packaging of Syft is [community maintained](https://github.com/NixOS/nixpkgs/blob/master/pkgs/tools/admin/syft/default.nix). Syft is available in the [stable channel](https://nixos.wiki/wiki/Nix_channels#The_official_channels) since NixOS`22.05`.
```bash
nix-env -i syft
@@ -109,9 +119,7 @@ The above output includes only software that is visible in the container (i.e.,
syft <image> --scope all-layers
```
## Supported sources
### Supported sources
Syft can generate a SBOM from a variety of sources:
@@ -131,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)
@@ -140,45 +149,74 @@ 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.
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).
### Default Cataloger Configuration by scan type
Syft uses different default sets of catalogers depending on what it is scanning: a container image or a directory on disk. The default 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 indicates software actually installed on an image.
However, if you are scanning a directory, Syft doesn't assume that all relevant software is installed, and will use catalogers that can identify declared dependencies that may not yet be installed on the final system: for example, dependencies listed in a Python requirements.txt.
You can override the list of enabled/disabled catalogers by using the "catalogers" keyword in the [Syft configuration file](https://github.com/anchore/syft#configuration).
##### Image Scanning:
- alpmdb
- rpmdb
- dpkgdb
- apkdb
-portage
- ruby-gemspec
- python-package
- php-composer-installed Cataloger
- javascript-package
- java
- go-module-binary
-binary
- dotnet-deps
- dotnet-portable-executable
- dpkgdb
- go-module-binary
- graalvm-native-image
- java
- javascript-package
- linux-kernel
- nix-store
- php-composer-installed
- portage
- python-package
- rpm-db
- ruby-gemspec
- sbom
##### 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
-binary
- cocoapods
- conan
-hackage
-dartlang-lock
- dotnet-deps
- dotnet-portable-executable
- dpkgdb
- elixir-mix-lock
- erlang-rebar-lock
- go-mod-file
- go-module-binary
- graalvm-native-image
- haskell
- java
- java-gradle-lockfile
- java-pom
- javascript-lock
- linux-kernel
- nix-store
- php-composer-lock
- portage
- python-index
- python-package
- rpm-db
- rpm-file
- ruby-gemfile
- rust-cargo-lock
- sbom
- swift-package-manager
#### Non Default:
##### Non Default:
- cargo-auditable-binary
### Excluding file paths
@@ -208,14 +246,16 @@ syft <image> -o <format>
```
Where the `formats` available are:
-`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
@@ -228,7 +268,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`.
@@ -251,13 +291,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:
- Syft JSON
- SPDX 2.2 JSON
- SPDX 2.2 tag-value
- CycloneDX 1.4 JSON
- CycloneDX 1.4 XML
- Syft JSON (```-o syft-json```)
- SPDX 2.2 JSON (```-o spdx-json```)
- SPDX 2.2 tag-value (```-o spdx-tag-value```)
- CycloneDX 1.4 JSON (```-o cyclonedx-json```)
- CycloneDX 1.4 XML (```-o cyclonedx-xml```)
Conversion example:
```sh
@@ -366,6 +408,8 @@ syft convert sbom.syft.json -o cyclonedx-json=sbom.cdx.json # convert it to Cyc
### Keyless support
Syft supports generating attestations using cosign's [keyless](https://github.com/sigstore/cosign/blob/main/KEYLESS.md) signatures.
Note: users need to have >= v1.12.0 of cosign installed for this command to function
To use this feature with a format like CycloneDX json simply run:
```
syft attest --output cyclonedx-json <IMAGE WITH OCI WRITE ACCESS>
returnnil,fmt.Errorf("could not generate source input for attest command: %w",err)
}
switchsi.Scheme{
casesource.ImageScheme,source.UnknownScheme:
// at this point we know that it cannot be dir: or file: schemes;
// we will assume that the unknown scheme could represent an image;
si.Scheme=source.ImageScheme
default:
returnnil,fmt.Errorf("attest command can only be used with image sources but discovered %q when given %q",si.Scheme,userInput)
}
// if the original detection was from the local daemon we want to short circuit
// that and attempt to generate the image source from its current registry source instead
switchsi.ImageSource{
caseimage.UnknownSource,image.OciRegistrySource:
si.ImageSource=image.OciRegistrySource
caseimage.SingularitySource:
default:
returnnil,fmt.Errorf("attest command can only be used with image sources fetch directly from the registry, but discovered an image source of %q when given %q",si.ImageSource,userInput)
returnnil,fmt.Errorf("cannot generate attestation since no repo digests were found; make sure you're passing an OCI registry source for the attest command")
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",
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",
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.