The scanner component of the devguard project

devguard-scanner

744-webhook-is-created-with-to-many-triggers

fix/create-assetversion-bug

0.10.0 troubleshooting-sast

integration-tests

fix-nil-pointer

361-unknown-created-the-ticket

l3monKenji-patch-2

293-allow-users-to-specify-access-scope-when-generating-personal-access-tokens

604-first-party-vuln-tickets-have-the-wrong-filelink-the-line-should-actually-be-included-in-the-link

710-add-docs-link-to-created-tickets

admin-token

l3monKenji-patch-1

626-replace-multiple-scan-timestamp-columns-with-unified-json-field

fix/latestTag-name

fix/vuln-event-query

fix-lint

fix/dependency-graph

postgres-cycle-detection

262-remove-projects

328-add-attestations-to-each-asset-version

434-ensure-we-sanitise-sarif-reports---especially-secret-scanning-eg-obfuscate-high-entropy-strings-from-secret-scans

294-devguard-scanner-does-not-panic-we-need-to-recheck-all-and-we-need-some-more-thouroughly-testing

validate-webhook-secret

748-write-tests-using-containers-for-different-functions

add-mechanical-justification

363-dependency-graph-endpoint

feature/sast-integration

601-remove-first-party-scan-results-log

fix/scan-result-vulns-amount

fix-bugs

add-integrations-tests

282-whole-system-crash-when-sending-empty-gitlab-string

365-multiple-instances-of-the-same-cve-in-an-asset

274-handleevent-crashes-with-first-party-vulnerabilities-in-githubgitlab-integration

325-rename-certain-things-to-make-them-more-clear

fix/handling-empty-slice-components

dates-in-vulnerability-events

0.8.3 feature/add-prometheus-metrics

fix/metadata-nil

fix/risk-recalculated-time

HEAD

269-improve-auto-setup-use-dynamic-api-and-webhook-urls-for-gitlab-integration

feature/code-coverage-report

678-overhaul-the-looks-of-a-ticket-generated-by-devguard

0.11.1 feature/deps.dev

fix/tag-or-branche-function

362-risk-handling-table-does-not-filter-anymore

attestations

fix/secret-update

0.9.1 742-assets-do-not-get-deleted-when-pressing-delete

add-api-url

fix/defaultbranch-tag

copy-vuln-events

614-only-project-members-should-be-able-to-handle-tickets

522-add-config-file-endpoints-to-asset-project-and-organization

ci-updates

ticket-handling

gitlab-oauth2

lookup

251-button-to-upload-an-sbom-manually

659-license-overwrite

437-error-in-devguard-deploy-step

add-secrets-option-to-asset

360-devguard-scanner-link-is-incorrect

fix/test-names

386-change-the-dependency-vulns-table-to-be-able-to-have-multiple-scanner-ids

388-automatic-ticket-creation-creates-tickets-for-already-accepted-vulnerabilities

add/integrations-tests

426-update-and-close-tickets-in-risk-daemon

0.8.2 feature/rego-eval

0.10.1 fix/raw-riskassessment-values

358-webhook-doesnt-work-anymore

add-asset-events-endpoint

chore/terms

chore/remove-version-from-components

fix/needed-scope

chore/improve-helm-chart-web-component

fix/event-query

feature/sbom-command

364-add-dependency-graph-to-github-and-gitlab-tickets-using-mermaidjs

fix/add-sbom-cli

simplify-ticket-creation

541-add-sbom-scanning-to-daemons-currently-we-only-recalculate-the-risks-but-do-not-detect-new-ones

249-devguard-scanner-should-panic-if-error-occurs

update-badge-api

565-add-webhook_secret-column-to-assets

main

673-mockeryyaml-is-wronlgy-formatted

558-scan-daemon-scans-asset-versions-from-deleted-assets

258-unable-to-create-organization-with-an-existing-name

535-add-information-about-the-amount-of-vulnerabilities-with-known-exploits-to-the-dashboard

289-automatically-create-ticket-for-high-risk-or-or-high-cvss-vulnerabilities

629-add-last-scan-information-to-asset-version-dto

fix-clientfactory

Devguard-Pipeline

Badge API Documentation

Badge API

Badge API Programm ZenDiS

quay.io/jetstack/cert-manager-acmesolver

ghcr.io/l3montree-dev/devguard-operator

ghcr.io/l3montree-dev/devguard-postgresql

ghcr.io/l3montree-dev/devguard

docker.io/oryd/kratos

devguard-action

Devguard Postgresql

DevGuard Operator

 Devguard-Pipeline

devguard-documentation

devguard

devguard-web

Devguard

Robot User

Badge-API

Lars Hermges

Patrick Rissmann

Sebastian Kawelke

Tim Bastin

Refaei Shikho

Frédéric Noppe

refoo0

timbastin

seb-kw

devguard-bot-dev[bot]

L3montree Cybersecurity

This is a scan for Devguard CI/CD components in a GitLab project, aimed at testing whether these components function correctly.

The documentation for the DevGuard Project

Manage your CVEs seamlessly, Integrate your Vulnerability Scanners, Documentation made easy, Compliance to security Frameworks - OWASP Incubating Project

Moby is an open-source project created by Docker to enable software containerization. The classic builder cache system is prone to cache poisoning if the image is built FROM scratch. Also, changes to some instructions (most important being HEALTHCHECK and ONBUILD) would not cause a cache miss. An attacker with the knowledge of the Dockerfile someone is using could poison their cache by making them pull a specially crafted image that would be considered as a valid cache candidate for some build steps. 23.0+ users are only affected if they explicitly opted out of Buildkit (DOCKER_BUILDKIT=0 environment variable) or are using the /build API endpoint. All users on versions older than 23.0 could be impacted. Image build API endpoint (/build) and ImageBuild function from github.com/docker/docker/client is also affected as it the uses classic builder by default. Patches are included in 24.0.9 and 25.0.2 releases.

Moby is an open-source project created by Docker for software containerization. A security vulnerability has been detected in certain versions of Docker Engine, which could allow an attacker to bypass authorization plugins (AuthZ) under specific circumstances. The base likelihood of this being exploited is low.

Using a specially-crafted API request, an Engine API client could make the daemon forward the request or response to an authorization plugin without the body. In certain circumstances, the authorization plugin may allow a request which it would have otherwise denied if the body had been forwarded to it.

A security issue was discovered In 2018, where an attacker could bypass AuthZ plugins using a specially crafted API request. This could lead to unauthorized actions, including privilege escalation. Although this issue was fixed in Docker Engine v18.09.1 in January 2019, the fix was not carried forward to later major versions, resulting in a regression. Anyone who depends on authorization plugins that introspect the request and/or response body to make access control decisions is potentially impacted.

Docker EE v19.03.x and all versions of Mirantis Container Runtime are not vulnerable.

docker-ce v27.1.1 containes patches to fix the vulnerability. Patches have also been merged into the master, 19.03, 20.0, 23.0, 24.0, 25.0, 26.0, and 26.1 release branches. If one is unable to upgrade immediately, avoid using AuthZ plugins and/or restrict access to the Docker API to trusted parties, following the principle of least privilege.

The various Is methods (IsPrivate, IsLoopback, etc) did not work as expected for IPv4-mapped IPv6 addresses, returning false for addresses which would return true in their traditional IPv4 forms.

The archive/zip package's handling of certain types of invalid zip files differs from the behavior of most zip implementations. This misalignment could be exploited to create an zip file with contents that vary depending on the implementation reading the file. The archive/zip package now rejects files containing these errors.

The net/http HTTP/1.1 client mishandled the case where a server responds to a request with an "Expect: 100-continue" header with a non-informational (200 or higher) status. This mishandling could leave a client connection in an invalid state, where the next request sent on the connection will fail. An attacker sending a request to a net/http/httputil.ReverseProxy proxy can exploit this mishandling to cause a denial of service by sending "Expect: 100-continue" requests which elicit a non-informational response from the backend. Each such request leaves the proxy with an invalid connection, and causes one subsequent request using that connection to fail.

An attacker may cause an HTTP/2 endpoint to read arbitrary amounts of header data by sending an excessive number of CONTINUATION frames. Maintaining HPACK state requires parsing and processing all HEADERS and CONTINUATION frames on a connection. When a request's headers exceed MaxHeaderBytes, no memory is allocated to store the excess headers, but they are still parsed. This permits an attacker to cause an HTTP/2 endpoint to read arbitrary amounts of header data, all associated with a request which is going to be rejected. These headers can include Huffman-encoded data which is significantly more expensive for the receiver to decode than for an attacker to send. The fix sets a limit on the amount of excess header frames we will process before closing a connection.

Due to the usage of a variable time instruction in the assembly implementation of an internal function, a small number of bits of secret scalars are leaked on the ppc64le architecture. Due to the way this function is used, we do not believe this leakage is enough to allow recovery of the private key when P-256 is used in any well known protocols.

Uncontrolled recursion in Decoder.Decode in encoding/gob before Go 1.17.12 and Go 1.18.4 allows an attacker to cause a panic due to stack exhaustion via a message which contains deeply nested structures.

Calling Decoder.Decode on a message which contains deeply nested structures can cause a panic due to stack exhaustion. This is a follow-up to CVE-2022-30635.

Calling Parse on a "// +build" build tag line with deeply nested expressions can cause a panic due to stack exhaustion.

Calling any of the Parse functions on Go source code which contains deeply nested literals can cause a panic due to stack exhaustion.

Allows arbitrary filesystem writes outside the extraction directory during extraction with filter="data".


You are affected by this vulnerability if using the tarfile module to extract untrusted tar archives using TarFile.extractall() or TarFile.extract() using the filter= parameter with a value of "data" or "tar". See the tarfile  extraction filters documentation https://docs.python.org/3/library/tarfile.html#tarfile-extraction-filter  for more information. Only Python versions 3.12 or later are affected by these vulnerabilities, earlier versions don't include the extraction filter feature.

Note that for Python 3.14 or later the default value of filter= changed from "no filtering" to `"data", so if you are relying on this new default behavior then your usage is also affected.

Note that none of these vulnerabilities significantly affect the installation of source distributions which are tar archives as source distributions already allow arbitrary code execution during the build process. However when evaluating source distributions it's important to avoid installing source distributions with suspicious links.

Allows the extraction filter to be ignored, allowing symlink targets to point outside the destination directory, and the modification of some file metadata.


You are affected by this vulnerability if using the tarfile module to extract untrusted tar archives using TarFile.extractall() or TarFile.extract() using the filter= parameter with a value of "data" or "tar". See the tarfile  extraction filters documentation https://docs.python.org/3/library/tarfile.html#tarfile-extraction-filter  for more information. Only Python versions 3.12 or later are affected by these vulnerabilities, earlier versions don't include the extraction filter feature.

Note that for Python 3.14 or later the default value of filter= changed from "no filtering" to `"data", so if you are relying on this new default behavior then your usage is also affected.

Note that none of these vulnerabilities significantly affect the installation of source distributions which are tar archives as source distributions already allow arbitrary code execution during the build process. However when evaluating source distributions it's important to avoid installing source distributions with suspicious links.

Allows modifying some file metadata (e.g. last modified) with filter="data" or file permissions (chmod) with filter="tar" of files outside the extraction directory.
You are affected by this vulnerability if using the tarfile module to extract untrusted tar archives using TarFile.extractall() or TarFile.extract() using the filter= parameter with a value of "data" or "tar". See the tarfile  extraction filters documentation https://docs.python.org/3/library/tarfile.html#tarfile-extraction-filter  for more information. Only Python versions 3.12 or later are affected by these vulnerabilities, earlier versions don't include the extraction filter feature.

Note that for Python 3.14 or later the default value of filter= changed from "no filtering" to `"data", so if you are relying on this new default behavior then your usage is also affected.

Note that none of these vulnerabilities significantly affect the installation of source distributions which are tar archives as source distributions already allow arbitrary code execution during the build process. However when evaluating source distributions it's important to avoid installing source distributions with suspicious links.

An issue was discovered in Cloud Native Computing Foundation (CNCF) Helm through 3.13.3. It displays values of secrets when the --dry-run flag is used. This is a security concern in some use cases, such as a --dry-run call by a CI/CD tool. NOTE: the vendor's position is that this behavior was introduced intentionally, and cannot be removed without breaking backwards compatibility (some users may be relying on these values). Also, it is not the Helm Project's responsibility if a user decides to use --dry-run within a CI/CD environment whose output is visible to unauthorized persons.

Issue summary: Applications performing certificate name checks (e.g., TLS
clients checking server certificates) may attempt to read an invalid memory
address resulting in abnormal termination of the application process.

Impact summary: Abnormal termination of an application can a cause a denial of
service.

Applications performing certificate name checks (e.g., TLS clients checking
server certificates) may attempt to read an invalid memory address when
comparing the expected name with an `otherName` subject alternative name of an
X.509 certificate. This may result in an exception that terminates the
application program.

Note that basic certificate chain validation (signatures, dates, ...) is not
affected, the denial of service can occur only when the application also
specifies an expected DNS name, Email address or IP address.

TLS servers rarely solicit client certificates, and even when they do, they
generally don't perform a name check against a reference identifier (expected
identity), but rather extract the presented identity after checking the
certificate chain.  So TLS servers are generally not affected and the severity
of the issue is Moderate.

The FIPS modules in 3.3, 3.2, 3.1 and 3.0 are not affected by this issue.

Issue summary: Use of the low-level GF(2^m) elliptic curve APIs with untrusted
explicit values for the field polynomial can lead to out-of-bounds memory reads
or writes.

Impact summary: Out of bound memory writes can lead to an application crash or
even a possibility of a remote code execution, however, in all the protocols
involving Elliptic Curve Cryptography that we're aware of, either only "named
curves" are supported, or, if explicit curve parameters are supported, they
specify an X9.62 encoding of binary (GF(2^m)) curves that can't represent
problematic input values. Thus the likelihood of existence of a vulnerable
application is low.

In particular, the X9.62 encoding is used for ECC keys in X.509 certificates,
so problematic inputs cannot occur in the context of processing X.509
certificates.  Any problematic use-cases would have to be using an "exotic"
curve encoding.

The affected APIs include: EC_GROUP_new_curve_GF2m(), EC_GROUP_new_from_params(),
and various supporting BN_GF2m_*() functions.

Applications working with "exotic" explicit binary (GF(2^m)) curve parameters,
that make it possible to represent invalid field polynomials with a zero
constant term, via the above or similar APIs, may terminate abruptly as a
result of reading or writing outside of array bounds.  Remote code execution
cannot easily be ruled out.

The FIPS modules in 3.3, 3.2, 3.1 and 3.0 are not affected by this issue.

Issue summary: A timing side-channel which could potentially allow recovering
the private key exists in the ECDSA signature computation.

Impact summary: A timing side-channel in ECDSA signature computations
could allow recovering the private key by an attacker. However, measuring
the timing would require either local access to the signing application or
a very fast network connection with low latency.

There is a timing signal of around 300 nanoseconds when the top word of
the inverted ECDSA nonce value is zero. This can happen with significant
probability only for some of the supported elliptic curves. In particular
the NIST P-521 curve is affected. To be able to measure this leak, the attacker
process must either be located in the same physical computer or must
have a very fast network connection with low latency. For that reason
the severity of this vulnerability is Low.

Issue summary: Clients using RFC7250 Raw Public Keys (RPKs) to authenticate a
server may fail to notice that the server was not authenticated, because
handshakes don't abort as expected when the SSL_VERIFY_PEER verification mode
is set.

Impact summary: TLS and DTLS connections using raw public keys may be
vulnerable to man-in-middle attacks when server authentication failure is not
detected by clients.

RPKs are disabled by default in both TLS clients and TLS servers.  The issue
only arises when TLS clients explicitly enable RPK use by the server, and the
server, likewise, enables sending of an RPK instead of an X.509 certificate
chain.  The affected clients are those that then rely on the handshake to
fail when the server's RPK fails to match one of the expected public keys,
by setting the verification mode to SSL_VERIFY_PEER.

Clients that enable server-side raw public keys can still find out that raw
public key verification failed by calling SSL_get_verify_result(), and those
that do, and take appropriate action, are not affected.  This issue was
introduced in the initial implementation of RPK support in OpenSSL 3.2.

The FIPS modules in 3.4, 3.3, 3.2, 3.1 and 3.0 are not affected by this issue.

ASTEVAL is an evaluator of Python expressions and statements. Prior to version 1.0.6, if an attacker can control the input to the `asteval` library, they can bypass asteval's restrictions and execute arbitrary Python code in the context of the application using the library. The vulnerability is rooted in how `asteval` performs handling of `FormattedValue` AST nodes. In particular, the `on_formattedvalue` value uses the dangerous format method of the str class. The code allows an attacker to manipulate the value of the string used in the dangerous call `fmt.format(__fstring__=val)`. This vulnerability can be exploited to access protected attributes by intentionally triggering an `AttributeError` exception. The attacker can then catch the exception and use its `obj` attribute to gain arbitrary access to sensitive or protected object properties. Version 1.0.6 fixes this issue.

musl libc 0.9.13 through 1.2.5 before 1.2.6 has an out-of-bounds write vulnerability when an attacker can trigger iconv conversion of untrusted EUC-KR text to UTF-8.

SSH servers which implement file transfer protocols are vulnerable to a denial of service attack from clients which complete the key exchange slowly, or not at all, causing pending content to be read into memory, but never transmitted.

Package	Max Risk	Max CVSS	Vulnerability Count	Installed Version	Action
github.com/docker/docker	MEDIUM (4.7)	CRITICAL (9.9)	2	24.0.0	Update to version 25.0.6+incompatible to reduce total risk by 8.3
stdlib	MEDIUM (4.5)	CRITICAL (9.8)	12	1.21.8	Update to version 1.23.8 to reduce total risk by 22.6
alpine/python3	MEDIUM (4.5)	CRITICAL (9.4)	4	3.12.10-r1	No fix available
helm.sh/helm/v3	MEDIUM (4.5)	CRITICAL (9.1)	1	3.17.3	No fix available
alpine/openssl	MEDIUM (4.3)	HIGH (7.5)	4	3.3.1-r3	No fix available
asteval	LOW (3.9)	HIGH (8.4)	1	1.0.5	No fix available
alpine/musl	LOW (3.8)	HIGH (8.1)	1	1.2.5-r0	No fix available
alpine/musl	LOW (3.8)	HIGH (8.1)	1	1.2.5-r9	No fix available
golang.org/x/crypto	LOW (2.6)	HIGH (7.5)	1	0.32.0	Update to version 0.35.0 to reduce total risk by 2.6

/Devguard
Project
/devguard-scanner
Repository

Identified Risks