chore(ci): remove Sonar #355
Loading…
x
Reference in New Issue
Block a user
No description provided.
Delete Branch "luke-patch-1"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Okay, here's a breakdown of the changes proposed in the provided Git diff:
Summary:
The CI workflow configuration file
.gitea/workflows/ci.yml
has been modified. The key changes involve disabling the existing SonarQube and Snyk vulnerability scans, and introducing a new Trivy vulnerability scan.Detailed Explanation:
Commenting out SonarQube Scan:
The original SonarQube Scan job is now commented out using
#
. This effectively disables the SonarQube code quality and security analysis during the CI process. Theuses
directive specifies the SonarSource GitHub Action. Theenv
section defines the environment variables required for the SonarQube scan, including the host URL and token, sourced from Gitea secrets. By commenting it out, this step is skipped.Commenting out Snyk Vulnerability Scan:
Similarly, the Snyk Vulnerability Scan job is also commented out. This disables the Snyk vulnerability scanning during CI. The
uses
directive specifies the Snyk GitHub Action.continue-on-error: true
is set to allow the workflow to proceed even if vulnerabilities are found. Theenv
section defines the Snyk token, sourced from Gitea secrets. Thewith
section configures the Snyk command to test all projects. By commenting it out, this step is skipped.Adding Trivy Vulnerability Scan:
A new job is added to perform vulnerability scanning using Trivy. Let's break down the configuration:
uses: aquasecurity/trivy-action@0.30.0
: This specifies that the job will use the Trivy GitHub Action, version 0.30.0.scan-type: "fs"
: This indicates that Trivy will perform a file system scan.scan-ref: "${{ gitea.workspace }}"
: This specifies the directory to scan, which is the Gitea workspace (the root of the repository).exit-code: "1"
: This means the action will exit with a non-zero exit code (failure) if vulnerabilities are found.ignore-unfixed: true
: This setting configures Trivy to disregard vulnerabilities that lack a readily available fix.format: "table"
: The scan results will be formatted as a table in the CI output.severity: "CRITICAL,HIGH,MEDIUM"
: Trivy will report vulnerabilities with CRITICAL, HIGH, or MEDIUM severity.scanners: "vuln,secret,misconfig,license"
: Trivy will scan for vulnerabilities, secrets, misconfigurations, and license issues.In Summary: The changes propose replacing SonarQube and Snyk scans with a Trivy scan, configured to scan the filesystem for vulnerabilities, secrets, misconfigurations and license issues, with specified severity levels. The existing scans have been disabled, not removed completely, by commenting out the relevant sections in the YAML file.
Decision: Reject
Change Score: 3/10
These changes are problematic and introduce unnecessary complexity and potential risks. Here's why:
pyproject.toml
anduv.lock
are incredibly hacky. This disrupts the build environment and suggests a misunderstanding of how Snyk should be integrated. Also generatingrequirements.txt
withuv pip freeze
is wrong because you're usinguv
which usespyproject.toml
and notrequirements.txt
.sed
command likely addresses an issue with workspace paths in coverage reports. Instead of commenting it out, fix the underlying issue or provide a proper alternative. Thecoverage xml
command was also removed, meaning no xml coverage report will be generated.verify=False
) in the n8n utility functions is a HUGE security risk. This makes the application vulnerable to man-in-the-middle attacks.snyk test
andsnyk code test
?Here's how I would address these issues:
Snyk Integration: Properly integrate Snyk without resorting to renaming or moving files. Consult Snyk's documentation for recommended workflows with
pyproject.toml
based projects. If you're just trying to scan the code and not the dependencies, usesnyk code test
without modifying the files.SonarQube: Reinstate the SonarQube scan. If there are issues, address them directly instead of disabling the scan.
Coverage Reports: Fix the workspace path issue in coverage reports properly. The
sed
command was likely a workaround, but a better solution might involve configuring the coverage tool or adjusting the workspace environment. Reinstate the xml report generation.SSL Verification: NEVER disable SSL verification in production code. This is a critical security vulnerability.
Here are the changes I recommend.
I have omitted the
requirements.txt
change, since generating this file is unecessary. I have also omitted the.gitignore
entry for the same reason.chore(ci): switch to Trivyto chore(ci): remove Sonar