oss-forensics

Name: oss-forensics
Author: AlexAI-MCP

132stars24forks

How to install oss-forensics?

alexai-mcp/hermes-ccc/oss-forensics

$npx -y skills add AlexAI-MCP/hermes-CCC --skill oss-forensics

Installs into the current project.

Summary

Open-source security forensics - analyze repositories, dependencies, and code for malicious patterns, supply chain risks, and vulnerabilities.

Files · 1

View on GitHub

SKILL.md

1	# OSS Forensics
2
3	## Purpose
4
5	- Use this skill to investigate open-source repositories, packages, images, and dependency trees for security risk.
6	- It is useful for package intake, third-party code review, incident response, and supply-chain due diligence.
7	- Treat this as a forensic and risk-triage workflow, not a single tool.
8
9	## High-Level Approach
10
11	1. Audit dependencies for known vulnerabilities.
12	2. Assess repository trust signals and maintainer health.
13	3. Review code for suspicious patterns.
14	4. Generate an SBOM and map packages to CVEs.
15	5. Check history, provenance, and release integrity.
16
17	## Dependency Audit
18
19	Python:
20
21	```bash
22	pip audit
23	```
24
25	Node:
26
27	```bash
28	npm audit
29	```
30
31	Rust:
32
33	```bash
34	cargo audit
35	```
36
37	- Start with ecosystem-native audit tools because they surface known advisories quickly.
38	- Audit output is a first-pass signal, not a complete security assessment.
39
40	## Repository Trust Review
41
42	- Check stars, forks, contributors, and recent activity.
43	- Look for consistent release cadence rather than vanity popularity alone.
44	- Review the maintainer set and whether development is concentrated in one fragile account.
45	- Inspect open issues and unresolved security reports.
46	- Check whether CI appears healthy and whether releases are reproducible.
47
48	## Maintainer Reputation Signals
49
50	- Is the maintainer known in the ecosystem.
51	- Does the project have multiple active reviewers.
52	- Are releases signed or provenance-documented.
53	- Has the project recently changed owners or transfer history.
54	- Did a previously dormant repo suddenly publish a new release with intrusive install-time behavior.
55
56	## Dependency Confusion
57
58	- Check whether private internal package names also exist publicly.
59	- If an internal package name is accidentally resolved from a public registry, it can become a dependency confusion vector.
60	- Review package names in lockfiles, private registries, and CI configuration.
61	- Ensure package managers are pinned to the intended registry for internal namespaces.
62
63	## Typosquatting Detection
64
65	- Compare the package name to well-known packages.
66	- Look for single-character swaps, dropped vowels, pluralization changes, or unicode lookalikes.
67	- Typosquatted packages often mimic metadata, README wording, or install instructions.
68	- Review whether the package description feels copied but inconsistent with the code quality.
69
70	## License Compliance
71
72	Python:
73
74	```bash
75	pip-licenses
76	```
77
78	Repository-level license detection:
79
80	```bash
81	licensee detect .
82	```
83
84	- Security review and license review are separate concerns, but intake usually needs both.
85	- Unexpected license changes can also be a signal that package ownership changed or quality control weakened.
86
87	## SBOM Generation
88
89	Using Syft:
90
91	```bash
92	syft .
93	syft image:myapp
94	```
95
96	CycloneDX example:
97
98	```bash
99	cyclonedx-bom
100	```
101
102	- Generate an SBOM to establish what is actually present.
103	- SBOMs are useful for later incident response, vulnerability matching, and compliance reporting.
104
105	## CVE Lookup
106
107	Container image scanning:
108
109	```bash
110	grype image:myapp
111	```
112
113	Filesystem scanning:
114
115	```bash
116	trivy fs ./
117	```
118
119	- Use `grype` for image/package matching against vulnerability databases.
120	- Use `trivy fs ./` for repository and local filesystem scanning.
121	- CVE output should be prioritized by exploitability, exposure, and runtime presence.
122
123	## Code Review for Malicious Patterns
124
125	Look for:
126
127	- obfuscated strings
128	- suspicious `eval()`
129	- suspicious `exec()`
130	- large base64 blobs
131	- dynamic network fetch during install
132	- shell command execution in setup hooks
133	- credential collection logic unrelated to the package purpose
134
135	These are not proof by themselves, but they deserve deeper inspection.
136
137	## Strings and Obfuscation Heuristics
138
139	- Long unreadable encoded literals
140	- split-and-join string tricks
141	- excessive use of reflection or metaprogramming in simple packages
142	- hidden payload assembly at runtime
143	- download-and-execute logic behind environment checks
144
145	## Git History Review
146
147	Check for suspicious edits and removed secrets:
148
149	```bash
150	git log --all -S 'password'
151	```
152
153	- Search history for credential strings, hardcoded tokens, or suspiciously removed secrets.
154	- Also inspect install scripts, CI files, release automation, and package publish workflows.
155	- A secret that existed and was later removed may still indicate a risky maintainer process.
156
157	## Release Integrity
158
159	- Verify package checksums when the ecosystem supports it.
160	- Prefer signed releases or trusted provenance where available.
161	- Compare source tarballs to repository tags when integrity matters.
162	- Watch for release artifacts that do not match the visible source tree.
163
164	## Supply-Cha

People who liked this also viewed

6 picks

Type

find-skillsHelps users discover and install agent skills when they ask questions like "how do I do X", "find a skill for X", "is there a skill that can...", or express interest in extending capabilities. This skSkillsJul 20262.6M27k
grill-meA relentless interview to sharpen a plan or design.SkillsJul 2026633k182k
vercel-react-best-practicesVercel's official collection of agent skillsSkillsJul 2026573k29k
improve-codebase-architectureScan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.SkillsJul 2026522k182k
setup-matt-pocock-skillsConfigure this repo for the engineering skills — set up its issue tracker, triage label vocabulary, and domain doc layout. Run once before first use of the other engineering skills.SkillsJul 2026454k182k
triageMove issues and external PRs through a state machine of triage roles — categorise, verify, grill if needed, and write agent-ready briefs.SkillsJul 2026424k182k

oss-forensics

132stars24forks

View on GitHub

How to install oss-forensics?

alexai-mcp/hermes-ccc/oss-forensics

$npx -y skills add AlexAI-MCP/hermes-CCC --skill oss-forensics

Installs into the current project.

Summary

Open-source security forensics - analyze repositories, dependencies, and code for malicious patterns, supply chain risks, and vulnerabilities.

Files · 1

View on GitHub

SKILL.md

1	# OSS Forensics
2
3	## Purpose
4
5	- Use this skill to investigate open-source repositories, packages, images, and dependency trees for security risk.
6	- It is useful for package intake, third-party code review, incident response, and supply-chain due diligence.
7	- Treat this as a forensic and risk-triage workflow, not a single tool.
8
9	## High-Level Approach
10
11	1. Audit dependencies for known vulnerabilities.
12	2. Assess repository trust signals and maintainer health.
13	3. Review code for suspicious patterns.
14	4. Generate an SBOM and map packages to CVEs.
15	5. Check history, provenance, and release integrity.
16
17	## Dependency Audit
18
19	Python:
20
21	```bash
22	pip audit
23	```
24
25	Node:
26
27	```bash
28	npm audit
29	```
30
31	Rust:
32
33	```bash
34	cargo audit
35	```
36
37	- Start with ecosystem-native audit tools because they surface known advisories quickly.
38	- Audit output is a first-pass signal, not a complete security assessment.
39
40	## Repository Trust Review
41
42	- Check stars, forks, contributors, and recent activity.
43	- Look for consistent release cadence rather than vanity popularity alone.
44	- Review the maintainer set and whether development is concentrated in one fragile account.
45	- Inspect open issues and unresolved security reports.
46	- Check whether CI appears healthy and whether releases are reproducible.
47
48	## Maintainer Reputation Signals
49
50	- Is the maintainer known in the ecosystem.
51	- Does the project have multiple active reviewers.
52	- Are releases signed or provenance-documented.
53	- Has the project recently changed owners or transfer history.
54	- Did a previously dormant repo suddenly publish a new release with intrusive install-time behavior.
55
56	## Dependency Confusion
57
58	- Check whether private internal package names also exist publicly.
59	- If an internal package name is accidentally resolved from a public registry, it can become a dependency confusion vector.
60	- Review package names in lockfiles, private registries, and CI configuration.
61	- Ensure package managers are pinned to the intended registry for internal namespaces.
62
63	## Typosquatting Detection
64
65	- Compare the package name to well-known packages.
66	- Look for single-character swaps, dropped vowels, pluralization changes, or unicode lookalikes.
67	- Typosquatted packages often mimic metadata, README wording, or install instructions.
68	- Review whether the package description feels copied but inconsistent with the code quality.
69
70	## License Compliance
71
72	Python:
73
74	```bash
75	pip-licenses
76	```
77
78	Repository-level license detection:
79
80	```bash
81	licensee detect .
82	```
83
84	- Security review and license review are separate concerns, but intake usually needs both.
85	- Unexpected license changes can also be a signal that package ownership changed or quality control weakened.
86
87	## SBOM Generation
88
89	Using Syft:
90
91	```bash
92	syft .
93	syft image:myapp
94	```
95
96	CycloneDX example:
97
98	```bash
99	cyclonedx-bom
100	```
101
102	- Generate an SBOM to establish what is actually present.
103	- SBOMs are useful for later incident response, vulnerability matching, and compliance reporting.
104
105	## CVE Lookup
106
107	Container image scanning:
108
109	```bash
110	grype image:myapp
111	```
112
113	Filesystem scanning:
114
115	```bash
116	trivy fs ./
117	```
118
119	- Use `grype` for image/package matching against vulnerability databases.
120	- Use `trivy fs ./` for repository and local filesystem scanning.
121	- CVE output should be prioritized by exploitability, exposure, and runtime presence.
122
123	## Code Review for Malicious Patterns
124
125	Look for:
126
127	- obfuscated strings
128	- suspicious `eval()`
129	- suspicious `exec()`
130	- large base64 blobs
131	- dynamic network fetch during install
132	- shell command execution in setup hooks
133	- credential collection logic unrelated to the package purpose
134
135	These are not proof by themselves, but they deserve deeper inspection.
136
137	## Strings and Obfuscation Heuristics
138
139	- Long unreadable encoded literals
140	- split-and-join string tricks
141	- excessive use of reflection or metaprogramming in simple packages
142	- hidden payload assembly at runtime
143	- download-and-execute logic behind environment checks
144
145	## Git History Review
146
147	Check for suspicious edits and removed secrets:
148
149	```bash
150	git log --all -S 'password'
151	```
152
153	- Search history for credential strings, hardcoded tokens, or suspiciously removed secrets.
154	- Also inspect install scripts, CI files, release automation, and package publish workflows.
155	- A secret that existed and was later removed may still indicate a risky maintainer process.
156
157	## Release Integrity
158
159	- Verify package checksums when the ecosystem supports it.
160	- Prefer signed releases or trusted provenance where available.
161	- Compare source tarballs to repository tags when integrity matters.
162	- Watch for release artifacts that do not match the visible source tree.
163
164	## Supply-Cha

People who liked this also viewed

6 picks

Type