The scanner component of the devguard project

devguard-scanner

glitchtip

feature/add-prometheus-metrics

fix/remove-test-json

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

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

803-normalize---ref-and---defaultref-paramter

chore/improve-helm-chart-web-component

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

fix/risks-search

0.10.0 fix/badge

add-integrations-tests

troubleshooting-sast

fix/defaultbranch-tag

fix/latestTag-name

0.8.2 feautre/jira-integration

fix-bugs

Hubtrick-Git-patch-1

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

attestations

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

add-mechanical-justification

feature/sbom-command

feature/sbom-report

feature/sast-integration

790-feature-request-upload-vex

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

524-scanner_id-is-still-used-in-the-new-loadpathtocomponent-function

add-asset-events-endpoint

integration-tests

lookup

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

363-dependency-graph-endpoint

fix/vuln-event-query

validate-webhook-secret

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

chore/remove-version-from-components

659-license-overwrite

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

add-scannerids-label

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

fix/secret-update

sarif-endpoint-new

add-secrets-option-to-asset

fix/tag-or-branche-function

267-cannot-create-new-asset-version-after-deleting-one-with-the-same-name

264-delete-asset-version

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

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

611-add-language-column-to-organization---we-might-need-to-translate-created-github-and-gitlab-tickets

wrong-link-in-devguard-attest-action

fix/nil-old-risk-assessment

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

fix/create-assetversion-bug

ticket-handling

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

266-remove-possible-double-slash-in-terminal-output-after-scanning-an-asset

gitlab-oauth2

fix/nil-pointer-deps-comp

356-only-automatically-create-tickets-if-there-is-no-other-asset-version-with-an-already-created-ticket-for-this-vulnerability

fix/add-sbom-cli

add-information-to-activity-stream

fix/handling-empty-slice-components

277-install-gitleaks-and-semgrep-in-dockerfilescanner

fix/risk-recalculated-time

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

fix/fixedversion-name

0.10.1 main

l3monKenji-patch-1

test-branch

change-user-id-by-detected-events

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

feature/code-coverage-report

fix-lint

298-fix-gitlab-webhook-integration

768-add-addtional-infos-to-vex

fix/dependency-graph

attest-integration

fix-clientfactory

HEAD

copy-vuln-events

291-fix-asset-version-name-in-events

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

fix/metadata-nil

add/integrations-tests

feature/rego-eval

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

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

idea/simplifies-interfaces

565-add-webhook_secret-column-to-assets

262-remove-projects

delete-not-active-asset-verions

777-error-message-that-an-account-with-the-e-mail-address-already-existss

l3monKenji-patch-2

ci-updates

0.8.3 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 Postgresql

DevGuard Operator

 Devguard-Pipeline

devguard-documentation

devguard-web

devguard

devguard-action

Devguard

Robot User

Badge-API

Lars Hermges

Patrick Rissmann

Sebastian Kawelke

Tim Bastin

David Luhmer

Refaei Shikho

Frédéric Noppe

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.

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.

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 v25.0.6+incompatible to reduce total risk by 8.3
stdlib	MEDIUM (4.5)	CRITICAL (9.8)	14	1.21.8	Update to version v1.23.8 to reduce total risk by 22.6
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

/Devguard
Project
/devguard-scanner
Repository

Identified Risks