PM-4777: Add binary scanning for Java artifacts (JAR, WAR, EAR, Spring Boot) - #524
PM-4777: Add binary scanning for Java artifacts (JAR, WAR, EAR, Spring Boot)#524dineshmistry wants to merge 1 commit into
Conversation
…g Boot) Adds `cycode scan -t sca binary <path>` and `cycode report sbom binary <path>`. The CLI opens a Java archive locally, identifies the open-source components inside it from embedded Maven metadata (pom.properties, then optionally a Maven Central SHA-1 lookup, then MANIFEST.MF), synthesises a CycloneDX 1.4 document, and feeds it to the existing SCA scan path. The archive itself is never uploaded. What ships: - Hardened zip reader (zip-slip, symlinks, absolute paths, compression and entry-count bombs, duplicate entry names read by central-directory record). - Identification ladder with an explicit `unidentified` result; no coordinate is ever guessed from a filename or an unshaped manifest value. - Dependency graph from containment plus real edges from embedded pom.xml (parsed with a DOCTYPE/ENTITY guard, no defusedxml needed). - `--max-depth`, `--offline`, `--maven-central` (opt-in, sends the hash only), `--project-name`, `--keep-bom`, `--include-binaries`. - Coverage line and JSON fields so CI can gate on identification, not guess. - `DigestResolver` seam so the Cycode backend digest index can replace the Maven Central implementation without caller changes. No new runtime dependency. All HTTP in tests is mocked with `responses`.
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
![cycode-security[bot]](https://avatars.githubusercontent.com/in/39308?s=60&v=4){kind=small}
| self._check_compression_ratio(entry, read_bytes) | ||
| self._budget.consume(len(chunk)) | ||
|
|
||
| sha1.update(chunk) |
There was a problem hiding this comment.
❗Cycode: SAST violation: 'Usage of weak hashing library (SHA-1)'.
Risk Score: 65 (MEDIUM)
Severity: Medium
Description
Using a weak hashing library like SHA-1 increases the risk of data breaches. SHA-1 in particular is vulnerable to collision attacks, where two different inputs can produce the same hash value, compromising data integrity and security.
Cycode Remediation Guideline
✅ Do
- Do opt for stronger hashing algorithms such as SHA-256 to enhance security.
hashlib.sha256('password').digest()
❌ Don't
- Do not use SHA-1 for hashing. It is no longer considered secure due to its vulnerability to collision attacks.
hashlib.sha1('password').digest() # unsafe
🎥 Learning materials (by Secure Code Warrior)
Tell us how you wish to proceed using one of the following commands:
| Tag | Short Description |
|---|---|
| #cycode_sast_false_positive <reason> | Mark as false positive — applies to this violation only |
| #cycode_sast_ignore_here <reason> | Ignore this violation — applies to this violation only |
| #cycode_ai_remediation | Request remediation guidance using Cycode AI |
There was a problem hiding this comment.
#cycode_sast_ignore_here
Intentional, non-cryptographic use. SHA-1 is the digest Maven Central and every artifact index key on, so it is the only algorithm a coordinate lookup can use; the call passes usedforsecurity=False, and SHA-256 is computed alongside and emitted in the BOM for anyone who wants a strong digest. Nothing here relies on SHA-1 for integrity or security.
There was a problem hiding this comment.
👎 This user is not permitted to perform actions.
| if not chunk: | ||
| break | ||
|
|
||
| digest.update(chunk) |
There was a problem hiding this comment.
❗Cycode: SAST violation: 'Usage of weak hashing library (SHA-1)'.
Risk Score: 65 (MEDIUM)
Severity: Medium
Description
Using a weak hashing library like SHA-1 increases the risk of data breaches. SHA-1 in particular is vulnerable to collision attacks, where two different inputs can produce the same hash value, compromising data integrity and security.
Cycode Remediation Guideline
✅ Do
- Do opt for stronger hashing algorithms such as SHA-256 to enhance security.
hashlib.sha256('password').digest()
❌ Don't
- Do not use SHA-1 for hashing. It is no longer considered secure due to its vulnerability to collision attacks.
hashlib.sha1('password').digest() # unsafe
🎥 Learning materials (by Secure Code Warrior)
Tell us how you wish to proceed using one of the following commands:
| Tag | Short Description |
|---|---|
| #cycode_sast_false_positive <reason> | Mark as false positive — applies to this violation only |
| #cycode_sast_ignore_here <reason> | Ignore this violation — applies to this violation only |
| #cycode_ai_remediation | Request remediation guidance using Cycode AI |
There was a problem hiding this comment.
#cycode_sast_ignore_here
Intentional, non-cryptographic use. SHA-1 is the digest Maven Central and every artifact index key on, so it is the only algorithm a coordinate lookup can use; the call passes usedforsecurity=False, and SHA-256 is computed alongside and emitted in the BOM for anyone who wants a strong digest. Nothing here relies on SHA-1 for integrity or security.
There was a problem hiding this comment.
👎 This user is not permitted to perform actions.
1 participant
What
Adds binary composition analysis to the CLI: point it at a built Java artifact and get the same SCA findings a source scan gives, plus an explicit account of what could not be identified.
Supported: JAR, WAR, EAR, Spring Boot fat JAR, nested archives to
--max-depth(default 3).How it works
META-INF/maven/**/pom.properties(exact) → optional Maven Central SHA-1 lookup with--maven-central(exact, opt-in, sends the hash only) →MANIFEST.MFattributes when they are shaped like real coordinates and carry a declared group (markedambiguous, never gates the exit code) → otherwise unidentified, reported by path, digest and size.cycode:evidence/cycode:confidence/cycode:pathproperties, and a dependency graph from containment overlaid with real edges from embeddedpom.xml.pom.xml(the engine routes a barebom.jsonto nothing), goes through the existingzip_documents→api/v4/scans/clipath. Nothing belowscan_documentschanges.Product stance
binary.unidentifiedin JSON, with a coverage line that is always printed and always true:9 identified (2 low confidence) | 7 unidentified | 23 vulnerabilities.Options
--max-depth--maven-central--offline--offline--project-name--monitoron a bare filename--keep-bom--include-binariesscan path, also extract Java archives met during the walkSecurity hardening in the reader
Zip-slip and absolute/drive/UNC paths, symlinks and non-regular entries, per-entry and total size limits, compression-ratio and entry-count bombs, truncated central directories, and duplicate entry names (Python's
ZipFile.open(name)returns the last duplicate; every entry is read from its ownZipInfoso a vulnerable jar cannot hide behind a patched one with the same name). Embeddedpom.xmlis refused if it carries a DOCTYPE or ENTITY declaration, which closes entity expansion without addingdefusedxml. Console output from entry names is stripped of rich markup, control characters and unbounded length.Verification
ruff checkandruff format --checkclean; Python 3.9 floor respected; all HTTP in tests mocked withresponses, including the Maven Central client.Not in this PR
DigestResolverseam; needs a backend endpoint that does not exist yet.BinaryExtractorinterface is ready; Java only ships now.jsonschema; a structural validator ships instead.main, not touched:report sbomprints "Report saved to" and writes no file (reproduces onreport sbom path .).Note on the ticket prefix
Branch and title use the product ticket
PM-4777. If aCM-ticket should own this, the title and branch are a rename away.🤖 Generated with Claude Code
https://claude.ai/code/session_01CmShLt7zGmitrn35FBPMw9