diff --git a/docs/community/maintainer/triage.md b/docs/community/maintainer/triage.md index 3e6eb4fa82..4d72fda693 100644 --- a/docs/community/maintainer/triage.md +++ b/docs/community/maintainer/triage.md @@ -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 diff --git a/docs/docs/integrations/github-actions.md b/docs/docs/integrations/github-actions.md index f14b2f6d87..2dade1051a 100644 --- a/docs/docs/integrations/github-actions.md +++ b/docs/docs/integrations/github-actions.md @@ -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 diff --git a/docs/docs/integrations/gitlab-ci.md b/docs/docs/integrations/gitlab-ci.md index 415d8ed6c2..c3107aac0c 100644 --- a/docs/docs/integrations/gitlab-ci.md +++ b/docs/docs/integrations/gitlab-ci.md @@ -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) diff --git a/docs/docs/kubernetes/cli/scanning.md b/docs/docs/kubernetes/cli/scanning.md index ee3d8c20fb..2f1ac72a79 100644 --- a/docs/docs/kubernetes/cli/scanning.md +++ b/docs/docs/kubernetes/cli/scanning.md @@ -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 diff --git a/docs/docs/kubernetes/operator/troubleshooting.md b/docs/docs/kubernetes/operator/troubleshooting.md index e592e099b1..a94334ff8e 100644 --- a/docs/docs/kubernetes/operator/troubleshooting.md +++ b/docs/docs/kubernetes/operator/troubleshooting.md @@ -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 ``` diff --git a/docs/docs/misconfiguration/custom/examples.md b/docs/docs/misconfiguration/custom/examples.md index fa2378c498..8bcae2e66f 100644 --- a/docs/docs/misconfiguration/custom/examples.md +++ b/docs/docs/misconfiguration/custom/examples.md @@ -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]. diff --git a/docs/docs/misconfiguration/policy/builtin.md b/docs/docs/misconfiguration/policy/builtin.md index 2bfd6d7a4d..50781ac5f5 100644 --- a/docs/docs/misconfiguration/policy/builtin.md +++ b/docs/docs/misconfiguration/policy/builtin.md @@ -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. diff --git a/docs/docs/vulnerability/scanning/git-repository.md b/docs/docs/vulnerability/scanning/git-repository.md index 65add69714..496ad0c8b5 100644 --- a/docs/docs/vulnerability/scanning/git-repository.md +++ b/docs/docs/vulnerability/scanning/git-repository.md @@ -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 | +---------------------+------------------+----------+-------------------+------------------------+---------------------------------------+ diff --git a/docs/index.md b/docs/index.md index 46467e7cf0..3103387d1e 100644 --- a/docs/index.md +++ b/docs/index.md @@ -22,17 +22,17 @@ All you need to do for scanning is to specify a target such as an image name of

Demo

-
+
Demo: Vulnerability Detection
-
+
Demo: Misconfiguration Detection
-
+
Demo: Secret Detection
diff --git a/helm/trivy/README.md b/helm/trivy/README.md index 89066bb0a4..f6218e0f1b 100644 --- a/helm/trivy/README.md +++ b/helm/trivy/README.md @@ -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/ diff --git a/integration/client_server_test.go b/integration/client_server_test.go index 7e2c5d4ea6..d0feb1bc35 100644 --- a/integration/client_server_test.go +++ b/integration/client_server_test.go @@ -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", }, diff --git a/integration/standalone_tar_test.go b/integration/standalone_tar_test.go index cbadd9392a..8779549aad 100644 --- a/integration/standalone_tar_test.go +++ b/integration/standalone_tar_test.go @@ -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", diff --git a/integration/testdata/almalinux-8.json.golden b/integration/testdata/almalinux-8.json.golden index 0d7080df0e..22fd2acee9 100644 --- a/integration/testdata/almalinux-8.json.golden +++ b/integration/testdata/almalinux-8.json.golden @@ -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" diff --git a/integration/testdata/fixtures/db/vulnerability.yaml b/integration/testdata/fixtures/db/vulnerability.yaml index e65fe531ce..cf29e03d7b 100644 --- a/integration/testdata/fixtures/db/vulnerability.yaml +++ b/integration/testdata/fixtures/db/vulnerability.yaml @@ -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: diff --git a/integration/testdata/fluentd-gems.json.golden b/integration/testdata/fluentd-gems.json.golden index 122d6c9a00..8ac3ecee59 100644 --- a/integration/testdata/fluentd-gems.json.golden +++ b/integration/testdata/fluentd-gems.json.golden @@ -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" diff --git a/integration/testdata/rockylinux-8.json.golden b/integration/testdata/rockylinux-8.json.golden index 05d68f6f02..1e491a5336 100644 --- a/integration/testdata/rockylinux-8.json.golden +++ b/integration/testdata/rockylinux-8.json.golden @@ -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" diff --git a/pkg/commands/artifact/run.go b/pkg/commands/artifact/run.go index fdc3f1a106..2f1ca99a4b 100644 --- a/pkg/commands/artifact/run.go +++ b/pkg/commands/artifact/run.go @@ -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) diff --git a/pkg/detector/ospkg/redhat/redhat.go b/pkg/detector/ospkg/redhat/redhat.go index 06013884ff..2e66ff8cd9 100644 --- a/pkg/detector/ospkg/redhat/redhat.go +++ b/pkg/detector/ospkg/redhat/redhat.go @@ -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 { diff --git a/pkg/rpc/client/client_test.go b/pkg/rpc/client/client_test.go index c24676b3e7..b7d805b78a 100644 --- a/pkg/rpc/client/client_test.go +++ b/pkg/rpc/client/client_test.go @@ -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, diff --git a/pkg/rpc/server/server.go b/pkg/rpc/server/server.go index 9bc128a68f..ad1ce7cd97 100644 --- a/pkg/rpc/server/server.go +++ b/pkg/rpc/server/server.go @@ -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} } diff --git a/rpc/cache/service.twirp.go b/rpc/cache/service.twirp.go index 2087821371..dd22a1119b 100644 --- a/rpc/cache/service.twirp.go +++ b/rpc/cache/service.twirp.go @@ -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 { diff --git a/rpc/scanner/service.twirp.go b/rpc/scanner/service.twirp.go index 6945989746..8e2add9d3f 100644 --- a/rpc/scanner/service.twirp.go +++ b/rpc/scanner/service.twirp.go @@ -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 {