Ignoring Vulnerabilities (NoSecHusky)
Relevant source files
The following files were used as context for generating this wiki page:
The NoSecHusky feature provides a mechanism for developers to intentionally ignore specific vulnerabilities or findings reported by huskyCI's security tools. This is useful for managing false positives or accepting known risks without blocking the CI/CD pipeline. When a vulnerability is marked to be ignored, huskyCI categorizes it as a "NoSec" issue, tracking it separately from other vulnerabilities and excluding it from the logic that determines if a pipeline should fail.
An example is ignoring a hardcoded password that is a false positive. By adding a #nohusky comment to the end of the line, the developer signals to huskyCI that this specific finding should be treated as an accepted risk. These ignored items are still tallied and displayed in the final analysis summary, ensuring they are not completely invisible.
Sources: README.md:32-35, README-ptBR.md:34-37
How It Works
The process of ignoring a vulnerability involves developer action within the source code, specific parsing logic in the huskyCI API for each security tool, and finally, aggregation and reporting in the huskyCI client.
Developer-Side Implementation
To ignore a potential vulnerability, a developer adds a specific comment to the line of code that is triggering the finding. The standard comment used is #nohusky.
For example, the Bandit security tool might flag the following line as a hardcoded password:
password = 'thisisnotapassword' #nohusky
By appending #nohusky, the developer indicates that this finding is intentional or a false positive and should be ignored by huskyCI's failure logic.
Sources: README.md:32-35, client/integration/sonarqube/testdata/analysis/vulnerable_python_project.json:115-121
API-Side Processing
When a security tool runs, its output is parsed by the huskyCI API. The parsers for tools like Brakeman and Bandit are designed to recognize their respective "ignore" syntaxes.
For instance, the Brakeman parser explicitly handles ignored_warnings from Brakeman's JSON output. It iterates through these warnings and creates HuskyCIVulnerability objects with a Severity of "NOSEC".
The following diagram illustrates the flow of how an ignored vulnerability is processed by the API.
This diagram shows the decision logic within the huskyCI API when parsing tool results.
Sources: api/securitytest/brakeman.go:73-84
A concrete example is the prepareBrakemanVulns function, which processes warnings from the Brakeman tool.
// api/securitytest/brakeman.go:73-84
for _, ignoredWarning := range brakemanOutput.IgnoredWarnings {
brakemanVuln := types.HuskyCIVulnerability{}
brakemanVuln.Language = "Ruby"
brakemanVuln.SecurityTool = "Brakeman"
brakemanVuln.Confidence = ignoredWarning.Confidence
brakemanVuln.Title = fmt.Sprintf("Vulnerable Dependency: %s %s", ignoredWarning.Type, ignoredWarning.Message)
brakemanVuln.Severity = "NOSEC"
brakemanVuln.Details = ignoredWarning.Details
brakemanVuln.File = ignoredWarning.File
brakemanVuln.Line = strconv.Itoa(ignoredWarning.Line)
brakemanVuln.Code = ignoredWarning.Code
brakemanVuln.Type = ignoredWarning.Type
huskyCIbrakemanResults.NoSecVulns = append(huskyCIbrakemanResults.NoSecVulns, brakemanVuln)
}
This logic is specific to each security tool's parser within the huskyCI API.
Sources: api/securitytest/brakeman.go:73-84
Data Structures
The ignored vulnerabilities are stored in a dedicated field within the analysis results. The HuskyCISecurityTestOutput struct contains a slice named NoSecVulns to hold these items.
This diagram shows the relationship between the main analysis data structures and the NoSecVulns field.
Sources: cli/types/types.go:122-127
The following table details the key data structures involved in tracking ignored vulnerabilities.
| Struct | Field | Type | Description |
|---|---|---|---|
HuskyCISecurityTestOutput | NoSecVulns | []HuskyCIVulnerability | A slice containing all vulnerabilities marked as ignored for a specific tool. |
HuskyCISummary | NoSecVuln | int | The total count of ignored vulnerabilities for a specific tool or for the entire analysis. |
Sources: cli/types/types.go:123, cli/types/types.go:146
An example from a Bandit scan shows how an ignored vulnerability is represented in the final JSON output:
// client/integration/sonarqube/testdata/analysis/vulnerable_python_project.json:114-122
"banditoutput": {
"nosecvulns": [
{
"language": "Python",
"securitytool": "Bandit",
"severity": "NOSEC",
"confidence": "MEDIUM",
"file": "./main.py",
"line": "3",
"code": "2 \n3 password = 'thisisnotapassword' #nohusky\n4 \n5 command = 'print \"this command is not secure!!\"'\n",
"details": "Possible hardcoded password: 'thisisnotapassword'"
}
],
Sources: client/integration/sonarqube/testdata/analysis/vulnerable_python_project.json:114-122
Reporting and Summarization
The huskyCI client is responsible for calculating and displaying the final summary, which includes the count of NoSecHusky items.
The prepareAllSummary function in the client aggregates counts from all security tools. It sums the length of each NoSecVulns slice to produce a total count of ignored vulnerabilities.
// client/analysis/output.go:261-262
totalNoSec = outputJSON.Summary.BrakemanSummary.NoSecVuln + outputJSON.Summary.BanditSummary.NoSecVuln + outputJSON.Summary.GosecSummary.NoSecVuln + outputJSON.Summary.GitleaksSummary.NoSecVuln
Sources: client/analysis/output.go:117, client/analysis/output.go:131, client/analysis/output.go:261-262
This summary is then printed to the console by the printAllSummary function, providing clear visibility into how many findings were intentionally ignored.
Example output:
[HUSKYCI][SUMMARY] Python -> huskyci/bandit:1.6.2
[HUSKYCI][SUMMARY] High: 0
[HUSKYCI][SUMMARY] Medium: 1
[HUSKYCI][SUMMARY] Low: 1
[HUSKYCI][SUMMARY] NoSecHusky: 1
Sources: README.md:37-42, client/analysis/output.go:320, client/analysis/output.go:334
Conclusion
The NoSecHusky feature is an essential part of huskyCI, providing a practical way for development teams to manage security findings. It allows them to acknowledge and accept certain risks or false positives by using a simple in-code comment (#nohusky). This prevents low-priority or irrelevant findings from breaking the build, while still ensuring that these ignored items are tracked and reported in the final analysis summary. This maintains a balance between automated security enforcement and developer productivity.