Threat Model
licit operates as a local audit tool. Its attack surface is limited, but there are risks to consider:
Identified Threats
| Threat | Severity | Mitigation |
|---|---|---|
| Provenance store manipulation | High | HMAC-SHA256 signing, Merkle tree integrity |
| Sensitive data in FRIA | Medium | .gitignore for fria-data.json, do not push to public repos |
| Injection via malicious YAML | Low | Exclusive use of yaml.safe_load() (not yaml.load()) |
| Compromised dependencies | Medium | Periodic auditing, minimum version pinning |
| Code execution via configs | Low | No code from configs is executed; only data is parsed |
| Contributor info exposure | Low | Provenance is not pushed by default; recommended in .gitignore |
What licit Does NOT Do
- Does not execute arbitrary code from the files it analyzes.
- Does not send data to external servers. Everything is processed locally.
- Does not require elevated permissions. It operates with the user’s permissions.
- Does not modify the source code of the analyzed project.
- Does not store credentials. Signing keys are managed by the user.
Cryptographic Signing (Provenance)
HMAC-SHA256
When provenance signing is enabled (provenance.sign: true), each record is signed with HMAC-SHA256:
signature = HMAC-SHA256(key, canonical_json(record))
Configuration:
provenance:
sign: true
sign_key_path: ~/.licit/signing-key
Key generation:
# Generate a 256-bit key
python3.12 -c "import secrets; print(secrets.token_hex(32))" > ~/.licit/signing-key
chmod 600 ~/.licit/signing-key
Attestation (Merkle Tree)
licit implements a Merkle tree over provenance records to detect manipulation:
root_hash
/ \
hash_01 hash_23
/ \ / \
hash_0 hash_1 hash_2 hash_3
| | | |
rec_0 rec_1 rec_2 rec_3
Any modification to a record invalidates the hash chain from that record to the root.
Implementation:
- Each record is serialized as canonical JSON (
sort_keys=True, default=str) - SHA256 of each record -> tree leaves
- Hash pairs are concatenated and re-hashed up to the root
- Odd records: the last one is duplicated to complete the pair
- Individual verification uses
hmac.compare_digest(timing-safe)
from licit.provenance.attestation import ProvenanceAttestor
attestor = ProvenanceAttestor() # Auto-generates key in .licit/.signing-key
# Sign an individual record
sig = attestor.sign_record({"file": "app.py", "source": "ai"})
# Verify integrity
assert attestor.verify_record({"file": "app.py", "source": "ai"}, sig)
# Sign a batch with Merkle tree
root = attestor.sign_batch([record1, record2, record3])
Key Management
The signing key is resolved in this order:
- Explicit path (
sign_key_pathin config) - Local fallback (
.licit/.signing-keyin the project) - Auto-generation (32 random bytes with
os.urandom(32))
All filesystem accesses are protected with try/except OSError.
Data Protection
Sensitive Data Generated by licit
| File | Sensitivity | Recommendation |
|---|---|---|
.licit.yaml | Low | Commit to repo |
.licit/provenance.jsonl | Medium | Do not commit (contains contributor info) |
.licit/fria-data.json | High | Do not commit (rights impact data) |
.licit/fria-report.md | Medium | Selective commit |
.licit/annex-iv.md | Low | Commit to repo |
.licit/changelog.md | Low | Commit to repo |
.licit/reports/* | Low | Commit to repo |
| Signing key | Critical | Never commit, 600 permissions |
Recommended .gitignore
# licit — sensitive data
.licit/provenance.jsonl
.licit/fria-data.json
# licit — signing key (if stored in the project)
.licit/signing-key
*.key
# licit — generated reports (optional, can be committed)
# .licit/reports/
Dependencies
Dependency Audit
licit uses 6 runtime dependencies, all widely adopted:
| Dependency | Min. version | Purpose | Maintainer |
|---|---|---|---|
| click | 8.1+ | CLI framework | Pallets |
| pydantic | 2.0+ | Config validation | Samuel Colvin |
| structlog | 24.1+ | Structured logging | Hynek Schlawack |
| pyyaml | 6.0+ | YAML parsing | YAML org |
| jinja2 | 3.1+ | Report templates | Pallets |
| cryptography | 42.0+ | HMAC-SHA256 | PyCA |
Recommendations
-
Pin versions in production: Use a
requirements.txtorpip-compileto lock exact versions. -
Audit regularly:
pip audit # Search for known vulnerabilities pip install pip-audit && pip-audit # Alternative -
Verify hashes:
pip install --require-hashes -r requirements.txt
Secure File Parsing
YAML
licit always uses yaml.safe_load() to parse YAML. Never yaml.load() (which allows arbitrary Python code execution).
# Correct (what licit does)
data = yaml.safe_load(f.read())
# NEVER (vulnerable to code execution)
# data = yaml.load(f.read(), Loader=yaml.FullLoader)
JSON
For SARIF and other JSON files, standard json.load() is used, which is safe by design.
Agent Configuration Files
Files like CLAUDE.md, .cursorrules, AGENTS.md are read as plain text. licit does not interpret or execute their content — it only analyzes them to detect changes and extract metadata.
External Process Execution
licit executes git commands via subprocess.run() with the following protections:
capture_output=True— stdout/stderr captured, not displayed directly.text=True— Automatic UTF-8 decoding.- No
shell=True— Arguments are passed as a list, not a string, preventing command injection. timeout=30— Explicit 30-second timeout ongit logto avoid blocking on massive repos (10 seconds forgit showand existence checks).subprocess.TimeoutExpiredcaught — returns an empty list without crashing.- Explicit
check=False— in allsubprocess.runcalls in provenance and changelog (does not raise an exception on returncode != 0). - Size guard (changelog):
ConfigWatcher._MAX_CONTENT_BYTES = 1_048_576— discardsgit showcontent larger than 1 MB to prevent OOM with accidentally tracked binary files.
# How licit executes git commands
result = subprocess.run(
["git", "rev-list", "--count", "HEAD"],
capture_output=True,
text=True,
)
Vulnerability Reporting
If you find a security vulnerability in licit:
- Do not open a public issue.
- Send an email to the maintainers with:
- Description of the vulnerability
- Steps to reproduce
- Potential impact
- You will receive an acknowledgment within 48 hours.
- A fix and advisory will be published once resolved.
See the SECURITY.md file in the project root for contact information.