gitea-mirror/trivy
1
0
Fork 0
mirror of https://github.com/aquasecurity/trivy.git synced 2025-12-12 15:50:15 -08:00
Code Issues Packages Projects Releases Wiki Activity

chore: fix spelling errors (#2352)

Browse Source
This commit is contained in:
Josh Soref
2022-06-20 02:56:13 -04:00
committed by GitHub
parent 6f1035269d
commit d6d0a60d16
22 changed files with 31 additions and 31 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
docs/community/maintainer/triage.md
View File

@@ -188,7 +188,7 @@ We use two labels [help wanted](https://github.com/aquasecurity/trivy/issues?q=i
and [good first issue](https://github.com/aquasecurity/trivy/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22)
to identify issues that have been specially groomed for new contributors.
We have specific [guidelines](/docs/docs/advanced/contribd/contrib/help-wanted.md)
We have specific [guidelines](/docs/community/maintainer/help-wanted.md)
for how to use these labels. If you see an issue that satisfies these
guidelines, you can add the `help wanted` label and the `good first issue` label.
Please note that adding the `good first issue` label must also

2
docs/docs/integrations/github-actions.md
View File

@@ -1,6 +1,6 @@
# GitHub Actions
- Here is the [Trivy Github Action][action]
- Here is the [Trivy GitHub Action][action]
- The Microsoft Azure team have written a [container-scan action][azure] that uses Trivy and Dockle
- For full control over the options specified to Trivy, this [blog post][blog] describes adding Trivy into your own GitHub action workflows

6
docs/docs/integrations/gitlab-ci.md
View File

@@ -111,7 +111,7 @@ container_scanning:
[example]: https://gitlab.com/aquasecurity/trivy-ci-test/pipelines
[repository]: https://github.com/aquasecurity/trivy-ci-test
### Gitlab CI alternative template
### GitLab CI alternative template
Depending on the edition of gitlab you have or your desired workflow, the
container scanning template may not meet your needs. As an addition to the
@@ -174,8 +174,8 @@ be necessary to rename the artifact if you want to reuse the name. To then
combine the previous artifact with the output of trivy, the following `jq`
command can be used, `jq -s 'add' prev-codeclimate.json trivy-codeclimate.json > gl-codeclimate.json`.
### Gitlab CI alternative template example report
### GitLab CI alternative template example report
You'll be able to see a full report in the Gitlab pipeline code quality UI, where filesystem vulnerabilities and misconfigurations include links to the flagged files and image vulnerabilities report the image/os or runtime/library that the vulnerability originates from instead.
You'll be able to see a full report in the GitLab pipeline code quality UI, where filesystem vulnerabilities and misconfigurations include links to the flagged files and image vulnerabilities report the image/os or runtime/library that the vulnerability originates from instead.
![codequality](../../imgs/gitlab-codequality.png)

2
docs/docs/kubernetes/cli/scanning.md
View File

@@ -27,7 +27,7 @@ Filter by severity:
$ trivy k8s --severity=CRITICAL --report=all cluster
```
Filter by security check (Vulnerabilties, Secrets or Misconfigurations):
Filter by security check (Vulnerabilities, Secrets or Misconfigurations):
```
$ trivy k8s --security-checks=secret --report=summary cluster

4
docs/docs/kubernetes/operator/troubleshooting.md
View File

@@ -65,11 +65,11 @@ Make sure that you are providing the right resources upon installing the Trivy O
If your pod is in `CrashLoopBackOff`, it is likely the case that the pod cannot be scheduled on the Kubernetes node that it is trying to schedule on.
In this case, you want to investigate further whether there is an issue with the node. It could for instance be the case that the node does not have sufficient resources.
## Reconcilation Error
## Reconciliation Error
It could happen that the pod appears to be running normally but does not reconcile the resources inside of your Kubernetes cluster.
Check the logs for reconcilation errors:
Check the logs for reconciliation errors:
```
kubectl logs deployment/trivy-operator -n trivy-system
```

2
docs/docs/misconfiguration/custom/examples.md
View File

@@ -6,7 +6,7 @@ See [here][k8s].
The custom policy is defined in `user.kubernetes.ID001` package.
You need to pass the package prefix you want to evaluate through `--namespaces` option.
In this case, the package prefix should be `user`, `user.kuberntes`, or `user.kubernetes.ID001`.
In this case, the package prefix should be `user`, `user.kubernetes`, or `user.kubernetes.ID001`.
### Dockerfile
See [here][dockerfile].

2
docs/docs/misconfiguration/policy/builtin.md
View File

@@ -16,7 +16,7 @@ Those policies are managed under [defsec repository][defsec].
For suggestions or issues regarding policy content, please open an issue under the [defsec][defsec] repository.
Helm Chart scanning will resolve the chart to Kubernetes manifests then run the [kubenetes][kubernetes] checks.
Helm Chart scanning will resolve the chart to Kubernetes manifests then run the [kubernetes][kubernetes] checks.
Ansible scanning is coming soon.

2
docs/docs/vulnerability/scanning/git-repository.md
View File

@@ -112,7 +112,7 @@ Total: 20 (UNKNOWN: 3, LOW: 0, MEDIUM: 7, HIGH: 5, CRITICAL: 5)
| | | | | | 2.11.3. The ReDOS... |
+---------------------+------------------+----------+-------------------+------------------------+---------------------------------------+
| py | CVE-2020-29651 | HIGH | 1.8.0 | | python-py: ReDoS in the py.path.svnwc |
| | | | | | component via mailicious input |
| | | | | | component via malicious input |
| | | | | | to blame functionality... |
| | | | | | -->avd.aquasec.com/nvd/cve-2020-29651 |
+---------------------+------------------+----------+-------------------+------------------------+---------------------------------------+

6
docs/index.md
View File

@@ -22,17 +22,17 @@ All you need to do for scanning is to specify a target such as an image name of
<h1 id="demo">Demo</h1>
</div>
<figure style="text-aligh: center">
<figure style="text-align: center">
<img src="imgs/vuln-demo.gif" width="1000">
<figcaption>Demo: Vulnerability Detection</figcaption>
</figure>
<figure style="text-aligh: center">
<figure style="text-align: center">
<img src="imgs/misconf-demo.gif" width="1000">
<figcaption>Demo: Misconfiguration Detection</figcaption>
</figure>
<figure style="text-aligh: center">
<figure style="text-align: center">
<img src="imgs/secret-demo.gif" width="1000">
<figcaption>Demo: Secret Detection</figcaption>
</figure>

2
helm/trivy/README.md
View File

@@ -18,7 +18,7 @@ This chart bootstraps a Trivy deployment on a [Kubernetes](http://kubernetes.io)
- Kubernetes 1.12+
- Helm 3+
## Installing from the the Aqua Chart Repository
## Installing from the Aqua Chart Repository
```
helm repo add aquasecurity https://aquasecurity.github.io/helm-charts/

2
integration/client_server_test.go
View File

@@ -225,7 +225,7 @@ func TestClientServer(t *testing.T) {
golden: "testdata/mariner-1.0.json.golden",
},
{
name: "buxybox with Cargo.lock",
name: "busybox with Cargo.lock",
args: csArgs{
Input: "testdata/fixtures/images/busybox-with-lockfile.tar.gz",
},

2
integration/standalone_tar_test.go
View File

@@ -240,7 +240,7 @@ func TestTar(t *testing.T) {
golden: "testdata/mariner-1.0.json.golden",
},
{
name: "buxybox with Cargo.lock integration",
name: "busybox with Cargo.lock integration",
testArgs: args{
Format: "json",
Input: "testdata/fixtures/images/busybox-with-lockfile.tar.gz",

2
integration/testdata/almalinux-8.json.golden vendored
View File

@@ -68,7 +68,7 @@
"URL": "https://errata.almalinux.org/"
},
"Title": "openssl: Read buffer overruns processing ASN.1 strings",
"Description": "ASN.1 strings are represented internally within OpenSSL as an ASN1_STRING structure which contains a buffer holding the string data and a field holding the buffer length. This contrasts with normal C strings which are repesented as a buffer for the string data which is terminated with a NUL (0) byte. Although not a strict requirement, ASN.1 strings that are parsed using OpenSSL's own \"d2i\" functions (and other similar parsing functions) as well as any string whose value has been set with the ASN1_STRING_set() function will additionally NUL terminate the byte array in the ASN1_STRING structure. However, it is possible for applications to directly construct valid ASN1_STRING structures which do not NUL terminate the byte array by directly setting the \"data\" and \"length\" fields in the ASN1_STRING array. This can also happen by using the ASN1_STRING_set0() function. Numerous OpenSSL functions that print ASN.1 data have been found to assume that the ASN1_STRING byte array will be NUL terminated, even though this is not guaranteed for strings that have been directly constructed. Where an application requests an ASN.1 structure to be printed, and where that ASN.1 structure contains ASN1_STRINGs that have been directly constructed by the application without NUL terminating the \"data\" field, then a read buffer overrun can occur. The same thing can also occur during name constraints processing of certificates (for example if a certificate has been directly constructed by the application instead of loading it via the OpenSSL parsing functions, and the certificate contains non NUL terminated ASN1_STRING structures). It can also occur in the X509_get1_email(), X509_REQ_get1_email() and X509_get1_ocsp() functions. If a malicious actor can cause an application to directly construct an ASN1_STRING and then process it through one of the affected OpenSSL functions then this issue could be hit. This might result in a crash (causing a Denial of Service attack). It could also result in the disclosure of private memory contents (such as private keys, or sensitive plaintext). Fixed in OpenSSL 1.1.1l (Affected 1.1.1-1.1.1k). Fixed in OpenSSL 1.0.2za (Affected 1.0.2-1.0.2y).",
"Description": "ASN.1 strings are represented internally within OpenSSL as an ASN1_STRING structure which contains a buffer holding the string data and a field holding the buffer length. This contrasts with normal C strings which are represented as a buffer for the string data which is terminated with a NUL (0) byte. Although not a strict requirement, ASN.1 strings that are parsed using OpenSSL's own \"d2i\" functions (and other similar parsing functions) as well as any string whose value has been set with the ASN1_STRING_set() function will additionally NUL terminate the byte array in the ASN1_STRING structure. However, it is possible for applications to directly construct valid ASN1_STRING structures which do not NUL terminate the byte array by directly setting the \"data\" and \"length\" fields in the ASN1_STRING array. This can also happen by using the ASN1_STRING_set0() function. Numerous OpenSSL functions that print ASN.1 data have been found to assume that the ASN1_STRING byte array will be NUL terminated, even though this is not guaranteed for strings that have been directly constructed. Where an application requests an ASN.1 structure to be printed, and where that ASN.1 structure contains ASN1_STRINGs that have been directly constructed by the application without NUL terminating the \"data\" field, then a read buffer overrun can occur. The same thing can also occur during name constraints processing of certificates (for example if a certificate has been directly constructed by the application instead of loading it via the OpenSSL parsing functions, and the certificate contains non NUL terminated ASN1_STRING structures). It can also occur in the X509_get1_email(), X509_REQ_get1_email() and X509_get1_ocsp() functions. If a malicious actor can cause an application to directly construct an ASN1_STRING and then process it through one of the affected OpenSSL functions then this issue could be hit. This might result in a crash (causing a Denial of Service attack). It could also result in the disclosure of private memory contents (such as private keys, or sensitive plaintext). Fixed in OpenSSL 1.1.1l (Affected 1.1.1-1.1.1k). Fixed in OpenSSL 1.0.2za (Affected 1.0.2-1.0.2y).",
"Severity": "MEDIUM",
"CweIDs": [
"CWE-125"

4
integration/testdata/fixtures/db/vulnerability.yaml vendored
View File

@@ -887,7 +887,7 @@
V3Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CweIDs:
- CWE-502
Description: A deserialization of untrusted data vulnernerability exists in rails < 5.2.4.3, rails < 6.0.3.1 that can allow an attacker to unmarshal user-provided objects in MemCacheStore and RedisCacheStore potentially resulting in an RCE.
Description: A deserialization of untrusted data vulnerability exists in rails < 5.2.4.3, rails < 6.0.3.1 that can allow an attacker to unmarshal user-provided objects in MemCacheStore and RedisCacheStore potentially resulting in an RCE.
LastModifiedDate: 2020-10-17T12:15:00Z
PublishedDate: 2020-06-19T18:15:00Z
References:
@@ -998,7 +998,7 @@
V3Vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:H
CweIDs:
- CWE-125
Description: ASN.1 strings are represented internally within OpenSSL as an ASN1_STRING structure which contains a buffer holding the string data and a field holding the buffer length. This contrasts with normal C strings which are repesented as a buffer for the string data which is terminated with a NUL (0) byte. Although not a strict requirement, ASN.1 strings that are parsed using OpenSSL's own "d2i" functions (and other similar parsing functions) as well as any string whose value has been set with the ASN1_STRING_set() function will additionally NUL terminate the byte array in the ASN1_STRING structure. However, it is possible for applications to directly construct valid ASN1_STRING structures which do not NUL terminate the byte array by directly setting the "data" and "length" fields in the ASN1_STRING array. This can also happen by using the ASN1_STRING_set0() function. Numerous OpenSSL functions that print ASN.1 data have been found to assume that the ASN1_STRING byte array will be NUL terminated, even though this is not guaranteed for strings that have been directly constructed. Where an application requests an ASN.1 structure to be printed, and where that ASN.1 structure contains ASN1_STRINGs that have been directly constructed by the application without NUL terminating the "data" field, then a read buffer overrun can occur. The same thing can also occur during name constraints processing of certificates (for example if a certificate has been directly constructed by the application instead of loading it via the OpenSSL parsing functions, and the certificate contains non NUL terminated ASN1_STRING structures). It can also occur in the X509_get1_email(), X509_REQ_get1_email() and X509_get1_ocsp() functions. If a malicious actor can cause an application to directly construct an ASN1_STRING and then process it through one of the affected OpenSSL functions then this issue could be hit. This might result in a crash (causing a Denial of Service attack). It could also result in the disclosure of private memory contents (such as private keys, or sensitive plaintext). Fixed in OpenSSL 1.1.1l (Affected 1.1.1-1.1.1k). Fixed in OpenSSL 1.0.2za (Affected 1.0.2-1.0.2y).
Description: ASN.1 strings are represented internally within OpenSSL as an ASN1_STRING structure which contains a buffer holding the string data and a field holding the buffer length. This contrasts with normal C strings which are represented as a buffer for the string data which is terminated with a NUL (0) byte. Although not a strict requirement, ASN.1 strings that are parsed using OpenSSL's own "d2i" functions (and other similar parsing functions) as well as any string whose value has been set with the ASN1_STRING_set() function will additionally NUL terminate the byte array in the ASN1_STRING structure. However, it is possible for applications to directly construct valid ASN1_STRING structures which do not NUL terminate the byte array by directly setting the "data" and "length" fields in the ASN1_STRING array. This can also happen by using the ASN1_STRING_set0() function. Numerous OpenSSL functions that print ASN.1 data have been found to assume that the ASN1_STRING byte array will be NUL terminated, even though this is not guaranteed for strings that have been directly constructed. Where an application requests an ASN.1 structure to be printed, and where that ASN.1 structure contains ASN1_STRINGs that have been directly constructed by the application without NUL terminating the "data" field, then a read buffer overrun can occur. The same thing can also occur during name constraints processing of certificates (for example if a certificate has been directly constructed by the application instead of loading it via the OpenSSL parsing functions, and the certificate contains non NUL terminated ASN1_STRING structures). It can also occur in the X509_get1_email(), X509_REQ_get1_email() and X509_get1_ocsp() functions. If a malicious actor can cause an application to directly construct an ASN1_STRING and then process it through one of the affected OpenSSL functions then this issue could be hit. This might result in a crash (causing a Denial of Service attack). It could also result in the disclosure of private memory contents (such as private keys, or sensitive plaintext). Fixed in OpenSSL 1.1.1l (Affected 1.1.1-1.1.1k). Fixed in OpenSSL 1.0.2za (Affected 1.0.2-1.0.2y).
LastModifiedDate: 2022-01-06T09:15:00Z
PublishedDate: 2021-08-24T15:15:00Z
References:

2
integration/testdata/fluentd-gems.json.golden vendored
View File

@@ -186,7 +186,7 @@
"URL": "https://github.com/advisories?query=type%3Areviewed+ecosystem%3Arubygems"
},
"Title": "rubygem-activesupport: potentially unintended unmarshalling of user-provided objects in MemCacheStore and RedisCacheStore",
"Description": "A deserialization of untrusted data vulnernerability exists in rails \u003c 5.2.4.3, rails \u003c 6.0.3.1 that can allow an attacker to unmarshal user-provided objects in MemCacheStore and RedisCacheStore potentially resulting in an RCE.",
"Description": "A deserialization of untrusted data vulnerability exists in rails \u003c 5.2.4.3, rails \u003c 6.0.3.1 that can allow an attacker to unmarshal user-provided objects in MemCacheStore and RedisCacheStore potentially resulting in an RCE.",
"Severity": "HIGH",
"CweIDs": [
"CWE-502"

2
integration/testdata/rockylinux-8.json.golden vendored
View File

@@ -68,7 +68,7 @@
"URL": "https://download.rockylinux.org/pub/rocky/"
},
"Title": "openssl: Read buffer overruns processing ASN.1 strings",
"Description": "ASN.1 strings are represented internally within OpenSSL as an ASN1_STRING structure which contains a buffer holding the string data and a field holding the buffer length. This contrasts with normal C strings which are repesented as a buffer for the string data which is terminated with a NUL (0) byte. Although not a strict requirement, ASN.1 strings that are parsed using OpenSSL's own \"d2i\" functions (and other similar parsing functions) as well as any string whose value has been set with the ASN1_STRING_set() function will additionally NUL terminate the byte array in the ASN1_STRING structure. However, it is possible for applications to directly construct valid ASN1_STRING structures which do not NUL terminate the byte array by directly setting the \"data\" and \"length\" fields in the ASN1_STRING array. This can also happen by using the ASN1_STRING_set0() function. Numerous OpenSSL functions that print ASN.1 data have been found to assume that the ASN1_STRING byte array will be NUL terminated, even though this is not guaranteed for strings that have been directly constructed. Where an application requests an ASN.1 structure to be printed, and where that ASN.1 structure contains ASN1_STRINGs that have been directly constructed by the application without NUL terminating the \"data\" field, then a read buffer overrun can occur. The same thing can also occur during name constraints processing of certificates (for example if a certificate has been directly constructed by the application instead of loading it via the OpenSSL parsing functions, and the certificate contains non NUL terminated ASN1_STRING structures). It can also occur in the X509_get1_email(), X509_REQ_get1_email() and X509_get1_ocsp() functions. If a malicious actor can cause an application to directly construct an ASN1_STRING and then process it through one of the affected OpenSSL functions then this issue could be hit. This might result in a crash (causing a Denial of Service attack). It could also result in the disclosure of private memory contents (such as private keys, or sensitive plaintext). Fixed in OpenSSL 1.1.1l (Affected 1.1.1-1.1.1k). Fixed in OpenSSL 1.0.2za (Affected 1.0.2-1.0.2y).",
"Description": "ASN.1 strings are represented internally within OpenSSL as an ASN1_STRING structure which contains a buffer holding the string data and a field holding the buffer length. This contrasts with normal C strings which are represented as a buffer for the string data which is terminated with a NUL (0) byte. Although not a strict requirement, ASN.1 strings that are parsed using OpenSSL's own \"d2i\" functions (and other similar parsing functions) as well as any string whose value has been set with the ASN1_STRING_set() function will additionally NUL terminate the byte array in the ASN1_STRING structure. However, it is possible for applications to directly construct valid ASN1_STRING structures which do not NUL terminate the byte array by directly setting the \"data\" and \"length\" fields in the ASN1_STRING array. This can also happen by using the ASN1_STRING_set0() function. Numerous OpenSSL functions that print ASN.1 data have been found to assume that the ASN1_STRING byte array will be NUL terminated, even though this is not guaranteed for strings that have been directly constructed. Where an application requests an ASN.1 structure to be printed, and where that ASN.1 structure contains ASN1_STRINGs that have been directly constructed by the application without NUL terminating the \"data\" field, then a read buffer overrun can occur. The same thing can also occur during name constraints processing of certificates (for example if a certificate has been directly constructed by the application instead of loading it via the OpenSSL parsing functions, and the certificate contains non NUL terminated ASN1_STRING structures). It can also occur in the X509_get1_email(), X509_REQ_get1_email() and X509_get1_ocsp() functions. If a malicious actor can cause an application to directly construct an ASN1_STRING and then process it through one of the affected OpenSSL functions then this issue could be hit. This might result in a crash (causing a Denial of Service attack). It could also result in the disclosure of private memory contents (such as private keys, or sensitive plaintext). Fixed in OpenSSL 1.1.1l (Affected 1.1.1-1.1.1k). Fixed in OpenSSL 1.0.2za (Affected 1.0.2-1.0.2y).",
"Severity": "MEDIUM",
"CweIDs": [
"CWE-125"

2
pkg/commands/artifact/run.go
View File

@@ -73,7 +73,7 @@ type Runner interface {
ScanFilesystem(ctx context.Context, opt Option) (types.Report, error)
// ScanRootfs scans rootfs
ScanRootfs(ctx context.Context, opt Option) (types.Report, error)
// ScanRepositroy scans repository
// ScanRepository scans repository
ScanRepository(ctx context.Context, opt Option) (types.Report, error)
// Filter filter a report
Filter(ctx context.Context, opt Option, report types.Report) (types.Report, error)

2
pkg/detector/ospkg/redhat/redhat.go
View File

@@ -97,7 +97,7 @@ func NewScanner(opts ...option) *Scanner {
}
}
// Detect scans and returns redhat vulenrabilities
// Detect scans and returns redhat vulnerabilities
func (s *Scanner) Detect(osVer string, _ *ftypes.Repository, pkgs []ftypes.Package) ([]types.DetectedVulnerability, error) {
log.Logger.Info("Detecting RHEL/CentOS vulnerabilities...")
if strings.Count(osVer, ".") > 0 {

4
pkg/rpc/client/client_test.go
View File

@@ -71,7 +71,7 @@ func TestScanner_Scan(t *testing.T) {
Title: "DoS",
Description: "Denial os Service",
Severity: common.Severity_CRITICAL,
References: []string{"http://exammple.com"},
References: []string{"http://example.com"},
SeveritySource: "nvd",
VendorSeverity: map[string]common.Severity{
string(vulnerability.NVD): common.Severity_MEDIUM,
@@ -119,7 +119,7 @@ func TestScanner_Scan(t *testing.T) {
Title: "DoS",
Description: "Denial os Service",
Severity: "CRITICAL",
References: []string{"http://exammple.com"},
References: []string{"http://example.com"},
VendorSeverity: dbTypes.VendorSeverity{
vulnerability.NVD: dbTypes.SeverityMedium,
vulnerability.RedHat: dbTypes.SeverityMedium,

2
pkg/rpc/server/server.go
View File

@@ -53,7 +53,7 @@ type CacheServer struct {
cache cache.Cache
}
// NewCacheServer is the facotry method for cacheServer
// NewCacheServer is the factory method for cacheServer
func NewCacheServer(c cache.Cache) *CacheServer {
return &CacheServer{cache: c}
}

4
rpc/cache/service.twirp.go vendored
View File

@@ -1469,8 +1469,8 @@ func writeError(ctx context.Context, resp http.ResponseWriter, err error, hooks
callResponseSent(ctx, hooks)
}
// sanitizeBaseURL parses the the baseURL, and adds the "http" scheme if needed.
// If the URL is unparsable, the baseURL is returned unchaged.
// sanitizeBaseURL parses the baseURL, and adds the "http" scheme if needed.
// If the URL is unparsable, the baseURL is returned unchanged.
func sanitizeBaseURL(baseURL string) string {
u, err := url.Parse(baseURL)
if err != nil {

4
rpc/scanner/service.twirp.go
View File

@@ -630,8 +630,8 @@ func writeError(ctx context.Context, resp http.ResponseWriter, err error, hooks
callResponseSent(ctx, hooks)
}
// sanitizeBaseURL parses the the baseURL, and adds the "http" scheme if needed.
// If the URL is unparsable, the baseURL is returned unchaged.
// sanitizeBaseURL parses the baseURL, and adds the "http" scheme if needed.
// If the URL is unparsable, the baseURL is returned unchanged.
func sanitizeBaseURL(baseURL string) string {
u, err := url.Parse(baseURL)
if err != nil {