Supply-chain attacks rarely start with something obvious.
They usually start with code that looks annoying to review: a long encoded string, a weird install script, a dynamic eval, a base64 decoder feeding a runtime execution sink, or some dependency update that adds one file you do not really want to read closely.
That is the dangerous part. Malicious code does not need to be clever forever. It only needs to survive review once.
That is why we built obfuscan.

It started as a core Critiq feature: a local scanner for obfuscated code and likely backdoors in diffs. The original plan was simple enough: keep it inside Critiq, make it part of the product, and use it as one more reason to use our Git workflow.
But the more we worked on it, the more obvious it became that this should not be closed.

What obfuscan actually detects

At its core, obfuscan scans code and diffs for patterns that show up again and again in real supply-chain attacks:

  • High-entropy string blobs
  • Base64, hex, gzip, or other decoder chains
  • Decode-then-execute patterns like eval(atob(...))
  • Network-then-execute patterns like curl | sh or fetch(...).text() into eval
  • Suspicious install-time behavior in manifests like package.json, setup.py, build.rs, Dockerfiles, and GitHub Actions
  • Unicode tricks like bidi controls and homoglyph identifiers
  • Unsafe deserializers and dynamic library loading
    It is not trying to prove intent. Static analysis cannot do that.
    What it can do is flag the shapes that are expensive and risky for humans to review manually, especially when they appear in the exact lines being changed.

Why scanning diffs matters

A lot of security tools scan whole repositories. That is useful, but it creates a practical problem: too much noise.
Reviewers do not usually need to know that an old vendored file has a long minified line. They need to know that this pull request added a suspicious decoder that feeds into a dynamic execution sink.

That difference matters.

Scanning diffs means:

  1. You focus on code that is actually changing
  2. Findings show up where the reviewer already has context
  3. The signal is closer to the decision point
    This is the same reason secret scanning is more useful before commit than after CI fails. The earlier the feedback appears, the cheaper it is to fix.

Why this started inside Critiq

Critiq is built around the idea that Git workflows should help you make better decisions before code gets shared.
That makes obfuscation detection a natural fit.
If a staged file adds a suspicious install script, or a pull request introduces decode-then-execute behavior, Critiq is exactly where that warning should appear. You are already looking at the change. You are already deciding what to commit, stage, or review.
So originally, obfuscan was going to live there as an internal Critiq capability.
That would have worked, but it would also have limited the impact.

Why we want this open source

Security detection gets better when people can inspect it, test it, and argue with it.
If obfuscan stayed closed, every false positive, bypass, missing decoder, or language gap would be ours alone to find. That is not how this category should work.
Open sourcing it gives the project a better path:

  • Detection rules can be reviewed instead of trusted blindly
  • Security researchers can add real-world bypasses as fixtures
  • Teams can tune or replace detectors for their own threat model
  • Language support can grow without waiting on us
  • Other tools can use the same engine outside Critiq
    This is especially important for supply-chain security. Attack patterns move quickly, and no single product team sees every ecosystem equally well.
    If someone finds a new malicious Python setup pattern, a strange PowerShell obfuscation trick, or a Rust build.rs behavior we missed, the right outcome is not a private ticket sitting in our backlog. The right outcome is a small rule or fixture that everyone can inspect and benefit from.

What open source does not mean

Open sourcing obfuscan does not mean Critiq loses the feature.
Critiq can still provide the polished workflow: local scanning, staged-file warnings, review UI, suppressions, and the parts that make the signal useful day to day.
The scanner itself should be portable.
That means you can use it in:

  • Git clients
  • Pre-commit hooks
  • CI jobs
  • VS Code extensions
  • Internal security review tools
  • Custom package auditing workflows
    The engine is just TypeScript. It takes source or diffs, runs detectors, and returns findings. Critiq becomes one of the best places to use it, not the only place it can live.

How it works today

obfuscan is split into two packages:

  • @obfuscan/core - the scanner engine and public API
  • @obfuscan/rules - language configs and query assets
    The default engine is intentionally lightweight. It uses regex/config-driven detectors and manifest parsing. It does not bundle parser grammars or execute code from the files it scans.
    For teams that want parser-backed analysis, the extension point is there. Hosts can provide their own tree-sitter grammars through RuleSet.loadGrammar() and GrammarHandle.parse(), then add custom detectors that call ctx.tree().
    That keeps the default package small while still leaving room for deeper analysis where it makes sense.

What we want from the community

The highest-value contributions are not huge rewrites.
They are usually small things:

  • Add a missing sink or decoder to a language config
  • Add a malicious fixture we currently miss
  • Add a benign fixture that prevents a noisy false positive
  • Improve coverage for an ecosystem we do not know as well
  • Report bypasses with safe, defanged examples
    This kind of project lives or dies on rule quality. The more real-world examples it sees, the better it gets.

Practical habits that still matter

Tools like obfuscan help, but they do not replace review.
Good habits still matter:

  • Treat install scripts as high-risk code
  • Be suspicious of encoded payloads in source
  • Review dynamic execution sinks carefully
  • Do not wave through generated-looking code just because it is hard to read
  • Keep allowlists narrow and reviewed
  • Prefer early feedback in the commit or PR flow over late CI surprises
    obfuscan is not a malware oracle.

It is a way to make suspicious code harder to miss.
That is enough to be useful. If it catches the weird decoder before it lands, or makes a reviewer stop and look twice at an install hook, it has done its job.
We still want Critiq to have the best version of that workflow. But the detection layer itself should be open, inspectable, and useful outside our product.
Supply-chain security is bigger than one Git client.
So obfuscan should be bigger than Critiq.

Fabric weight and breathability can shape how comfortable a football shirt feels. For a season-based comparison, Lionel Messi kids jersey（camiseta de Lionel Messi para niños） identifies the team or player linked to the design. The right option depends on whether the shirt is intended for collecting, gifting or regular wear.