Enterprise Cryptographic Discovery & Analysis Tool (ECDAT)

The receipts 🧾

Every red flag on this statement, in full. These are the four places it bites.

1. Exhibit A

   Statically finding all crypto usage is hard — dynamically loaded, wrapped or obfuscated crypto is missed, so honest coverage claims matter and a security judge will probe what you cannot detect

2. It gets worse

   Binary and container scanning is significantly harder than source scanning, so teams tend to do source only while claiming full coverage

3. Still reading?

   The PQC recommendations must reflect the finalised NIST standards, and recommending a withdrawn or unsuitable algorithm undermines credibility

4. And the finisher

   Business-criticality classification needs context the scanner cannot infer alone, so that dimension may be shallow without user input

The damage report 📉

Every score this statement earned, and what each one actually costs you.

• Feasibility

  4/5

  Actually buildable, which on this slate is rarer than it sounds. Do not squander it on scope.

  Static scanning for cryptographic usage in source code and libraries is achievable with pattern matching and AST analysis, open repositories and OpenSSL are named as fair game, the CBOM concept has emerging standards to follow, and Mosca's framework is a simple published formula — so the whole tool is buildable.

• Innovation scope

  3/5

  Mildly interesting. The novelty will not carry the room; the build has to.

  Cryptographic discovery and CBOM generation are an emerging but increasingly defined area, so your room is in scan coverage across artefact types and in the risk-classification and recommendation logic rather than in a novel concept.

• Clarity

  5/5

  The ask is unambiguous, which quietly removes your favourite excuse.

  The description enumerates exactly what to catalogue, names the Mosca framework, specifies the classification dimensions, the recommendation requirement, the CBOM report and the interactive GUI, making the deliverable precisely defined.

• Acceptance potential

  4/5

  Strong footing before you have written a line. Try not to waste it.

  A strong pick — post-quantum migration is a genuine current priority for exactly NTRO's constituency, the tool is buildable on open code, Mosca's framework gives your risk assessment an authoritative basis, and CBOM tooling is early enough that a solid entry stands out rather than competing with mature products.

• Effort

  Heavy

  Heavy. Somebody on this team is not sleeping in week three. Pick who, on purpose.

  Scanners across code, binaries, libraries and container images, the classification and risk engine, the recommendation logic and the CBOM report and GUI are focused pieces, with broad scan coverage the main effort.

• Demo-ability

  Easy

  Easy to demo — and so is everyone else's. Working is the floor here, not the achievement.

  Scanning a real repo and producing a CBOM with quantum-risk rankings and PQC recommendations is a clean, concrete demo with a tangible artifact at the end.

The demo they will have already seen 🪞

Somewhere around 70–160 teams are heading here, and the description is doing the choosing for most of them. They will read the same brief, reach the same architecture, and build a version of the same demo you are planning. Being correct is the floor. If your five minutes could be swapped with the team before you and nobody in the room would notice, you have not picked badly — you have built predictably, which costs exactly the same and hurts more.

What survives 🛡️

The ground worth standing on when the questions start.

• Open code repositories and OpenSSL are named as fair game, so you have unlimited real material to scan and demonstrate on
• Mosca's inequality is a simple published formula, so your quantum-risk scoring rests on an established framework rather than invention
• The CBOM concept has emerging standards like CycloneDX crypto to align to, giving your output an authoritative format