Source code
Deterministic parsing of useful files, without turning your codebase into an AI chat.
Understand CoreAnalyzer.
Start an analysis, read a report, choose a format or connect a technical workflow without searching through scattered pages.
Choose the path that matches your next action.
01 Run analysis Select a local project or an available GitHub source, then launch CoreAnalyzer. 02 Import report Open a JSON or .cdp report in the Web interface. 03 Compare two reports Use two JSON reports to read changes between analyses.
Start without a configuration file.
CoreAnalyzer applies its supported-language and framework context automatically. A YAML file is optional and only changes explicit scope or thresholds.
- Run a dry-run to inspect the files that will be included.
- Keep the defaults when the scope matches your project.
- Add targeted exclusions only for generated or irrelevant content. Tests can provide useful call and usage evidence.
A software map, not only a security list.
CoreAnalyzer maps the project structure before scoring risk. The available sections depend on the languages and files found. Each result stays attached to its category, location and evidence.
CoreAnalyzer maps project structure before scoring risk.
No noise for its own sake: a clear evidence base, file by file, line by line.
Application structure
Routes, entry points, dependencies and technical signals are mapped before risk scoring.
File/line evidence
Findings stay attached to file, line and project context for faster human review.
Project map
Files, languages, structure, routes, entry points, dependencies and the detected scope — including every exclusion and its reason — are mapped before risk scoring.
Quality and maintainability
Performance signals, duplications, unused-code candidates and code smells, with context when available.
Application coherence
Routes and APIs, front/back relationships, sockets and real-time flows identified in the project.
Security and exposure
Contextual security findings, sensitive files, dependencies, configuration and infrastructure signals.
Symbols proven to be used help establish the project map; they are not listed as anomalies. A statically ambiguous case is presented for review rather than as a confirmed defect.
Move from scope to evidence.
The overview helps prioritise. The category detail, source location, evidence and confidence level are what support a technical decision.
- Check the scope
Review included files and the excluded scope, which also covers unsupported formats, before interpreting totals.
- Use the overview to prioritise
Scores and totals orient the review; they do not replace the detailed findings.
- Open the relevant category
Separate architecture, maintainability, application-flow and security questions.
- Read the proof
Verify the file, line, reason, available context and confidence before changing code.
- Validate and preserve the result
Confirm the expected behaviour with your tests or runtime context, then export the report format required by your workflow.
Severity and confidence answer different questions.
Severity describes the potential impact. Confidence describes how strongly the available static evidence supports the finding.
Severity: potential impact if the finding conditions hold
- CriticalPotential systemic compromise, major data exposure or loss of control.
- HighPotential significant impact on confidentiality, integrity, privileges or availability.
- MediumConditional or contained impact that deserves planned remediation.
- LowLimited impact, hardening opportunity or local maintainability risk.
Severity is based on the reachable action or sink, the assets involved, exposure, visible safeguards and possible consequences. Repetition alone never makes a finding critical.
- Confirmed
- The required premises are demonstrated in the supplied code and flows. Review the cited source before remediation.
- Probable
- Several elements converge, but at least one premise still needs verification.
- Review
- The static context is incomplete. Treat the item as an investigation point, not an established defect.
- How confidence is established
- Confirmed means the required premises are demonstrated in the supplied code and flows. Probable keeps one premise open. Review requires dynamic, runtime or external context.
The global score is a prioritisation indicator, not a certificate.
It starts at 100 and summarises the retained signals in the analysed scope. A higher score means fewer priority signals were retained; it never proves that an application is vulnerability-free.
- Inputs
- Security, maintainability, application contracts such as routes and realtime, project hygiene, and effective analysis coverage.
- Weighting
- Potential impact and confidence are evaluated separately, then combined. Confirmed evidence affects prioritisation more than a point marked for review.
- Report counters
- Retained findings are the complete review set. Confirmed findings have all required premises proven in the supplied scope. Review priority combines confirmed and probable findings; items to verify remain visible without being presented as established defects.
- Noise control
- Repeated signals have a diminishing effect so one repeated mechanism does not overwhelm the score. Project scale is also considered.
- Coverage
- If a material source tree or analysis layer is missing, the scope is marked incomplete and the score becomes non-conclusive.
- Meaningful comparison
- Compare the same project with an equivalent scope, configuration and engine version. The score is not designed to rank unrelated projects.
- Limits
- The score is neither CVSS, an exploit probability, an audit opinion nor a security certification. Use it to order the review, then read the evidence.
One report, several controlled uses.
The native .cdp artifact preserves the CoreAnalyzer report with a verifiable CoreDevPro origin seal. The report remains a reusable technical object: it can be saved, re-imported in the Web interface, compared, used as AI context, then converted to JSON, PDF, HTML or CSV according to the offer. Encrypted .cdp uses AES-256-GCM.
| Format | Primary use | Availability |
|---|---|---|
| Native .cdp | Primary use Native CoreAnalyzer report with a CoreDevPro origin seal and locally verifiable integrity. | Availability Discovery, Essential, Pro and compatible Enterprise access |
| JSON | Primary use Optional structured export for compatible integrations, data processing and authorised agent workflows. | Availability Discovery, Essential and Pro |
| Encrypted .cdp | Primary use Report encrypted locally with AES-256-GCM for sensitive exchanges and storage; the passphrase is not sent to CoreDevPro. | Availability Pro and compatible Enterprise access |
| PDF / HTML / CSV | Primary use Readable or tabular derivatives generated from an open report. | Availability Essential and Pro |
| CycloneDX / SPDX / VEX / Action plan | Primary use Security and compliance deliverables generated when the dedicated export capability is enabled. | Availability Pro and compatible Enterprise access |
What the native .cdp proof establishes.
Verification uses the public CoreDevPro key registry. It checks the signed origin statement and payload digest without embedding an account email.
- Origin
- The signature matches a CoreDevPro public key pinned by the verifier.
- Integrity
- The signed payload digest is checked locally; for encrypted .cdp, this check completes after decryption.
- Time
- Version 2 records the server issue time. A qualified eIDAS timestamp is not claimed unless a qualified external token is present and validated.
- Privacy
- The envelope adds no account email or direct personal identifier. An encrypted .cdp passphrase stays in the browser or CLI.
coredevpro verify report.cdp coreanalyzer-mcp verify report.cdp Public key registry Public CDP v2 schema
Check a .cdp report directly in CoreAnalyzer.
Verification runs locally in the browser. A modified file, invalid signature or unrecognised key is rejected before the report can be opened.
Verify a .cdp report- 01 Select the file
Import the .cdp from the report-opening area.
- 02 Read the proof
CoreAnalyzer displays the CoreDevPro origin, content integrity and declared issue date separately.
- 03 Open only a validated report
The open button stays disabled when tampering or invalid proof is detected.
Available today CoreDevPro origin signature, SHA-256 digest and local verification.
Not active today Qualified eIDAS timestamping. The signed server date is never presented as certification.
SAI view
SAI is a reading layer for a report already produced by CoreAnalyzer. It organizes structures, routes, dependencies, file/line evidence and technical relationships for prioritisation and investigation, without replacing the analysis.
See the SAI viewWeb exports
Once a report is open, generate PDF, HTML or CSV usage formats when your plan enables them.
Understand report reuseContinue from the interface to your delivery workflow.
CLI Use CoreDevPro directly from a terminal. Install the CLI, sign in and run an interactive scan from your project. CI/CD Request a CI/CD integration. CoreDevPro prepares the repository, pipeline, secrets, YAML scope, quality gate and report artifact with you. PRODUCT TOUR See the complete report lifecycle. From the project selection screen to the report views and reusable artifacts. AGENTS Give an authorised agent a structured report. Use the native .cdp payload or the optional JSON export as structured context. CoreAnalyzer remains the component that analyses the project. MCP Connect an agent — Pro, beta on request. Start a standard scan, follow its state and read the complete public report through a controlled agent workflow. FAQ Find a precise answer quickly. Quotas, subscriptions, imports, reports and integration questions.
The same CoreAnalyzer pipeline, through a controlled agent interface.
PRIVATE BETA - INVITATION ONLY
MCP is reserved for invited Pro accounts, on request. A subscription alone does not activate access. Public registration and remote Git sources remain closed during qualification.
For server-accessible sources and existing scans
The Streamable HTTP endpoint is active for invited accounts. The local bridge sends a validated archive over HTTPS; public access and remote Git sources remain disabled during the beta.
https://coredevpro.fr/mcp For a folder present on the user’s machine
Run this command from the project folder. It signs in, registers the bridge and gives the agent one local action that applies exclusions and YAML, uploads the source corpus and starts the scan. No manual ZIP is required.
npx --prefer-online -y --package=https://coredevpro.fr/mcp-client/coreanalyzer-mcp-0.1.0-beta.17.tgz coreanalyzer-mcp setup --client codex One bridge, configured for the agent you already use.
Node.js 20 or later is required; reopen the terminal after installing it. Each command authorizes the current project and updates only the CoreAnalyzer entry. Existing MCP servers and JSONC comments are preserved; credentials never enter the editor configuration.
npx --prefer-online -y --package=https://coredevpro.fr/mcp-client/coreanalyzer-mcp-0.1.0-beta.17.tgz coreanalyzer-mcp setup --client all Uses the MCP configuration shared by the Codex CLI and VS Code extension. This remains the default when no client is specified.
npx --prefer-online -y --package=https://coredevpro.fr/mcp-client/coreanalyzer-mcp-0.1.0-beta.17.tgz coreanalyzer-mcp setup --client codex Writes the official mcpServers entry in ~/.cursor/mcp.json. Cursor IDE and Cursor Agent use the same server definition.
npx --prefer-online -y --package=https://coredevpro.fr/mcp-client/coreanalyzer-mcp-0.1.0-beta.17.tgz coreanalyzer-mcp setup --client cursor Writes the official stdio server entry in the user’s Code/User/mcp.json without replacing other configured servers.
npx --prefer-online -y --package=https://coredevpro.fr/mcp-client/coreanalyzer-mcp-0.1.0-beta.17.tgz coreanalyzer-mcp setup --client vscode Remote SSH, dev container or cloud workspace
Run setup in the environment that can read the project and choose workspace scope. The bridge then runs beside the code while the analysis still uses the standard CoreAnalyzer service.
npx --prefer-online -y --package=https://coredevpro.fr/mcp-client/coreanalyzer-mcp-0.1.0-beta.17.tgz coreanalyzer-mcp setup --client vscode --scope workspace - 01 Connect the account
The setup command asks for the regular CoreDevPro credentials in the terminal and stores only the protected account session. Passwords and access tokens are never MCP tool arguments.
- 02 Confirm the scope
CoreAnalyzer checks the plan, project binding, size, active modules and optional YAML before admission.
- 03 Run and follow
The scan uses the standard queue and workers. It continues if the agent disconnects and can be followed by its scan identifier.
- 04 Read and preserve
The agent reads public sections by page; the complete preservation artifact remains the signed, locally verifiable .cdp report.
Available contract
- Account
- Read effective capabilities, limits and authorised source types.
- Scan
- For a local folder, coreanalyzer.scan.local handles native exclusions, YAML, project identity, packaging and upload before admission. The agent then follows status and reads the signed report.
- Report
- Read the manifest, public sections and findings page by page. Confidence and evidence keep stable types. The SCA section is the dependency inventory and can be filtered to advisories only.
- Artifact
- Retrieve the signed .cdp through a short-lived ticket, verify it locally without uploading it, or purge the temporary snapshot early.
Configuration stays optional and explicit
Without YAML, CoreAnalyzer applies its standard language and framework context. A project YAML included in the folder or archive follows the CLI contract; the MCP does not silently rewrite it.
Read the YAML configuration guide Temporary by design
Source data is sent outside the model context, processed by the standard pipeline and purged. The public report snapshot expires after an absolute window of up to ten minutes by default; reading it does not extend that window.
Stable errors, clear limits
Authentication, scope, quota, upload, scan and report states use stable machine codes with French or English messages. Internal SAI thresholds and discarded signals are not exposed.
The complete report is not a summary
Pagination keeps agent context controlled. It never replaces the complete .cdp artifact, whose signed origin statement and payload digest can be verified locally through the bridge.
Read the boundaries before you connect a project.
The security documentation explains the implemented web and CI processing flows, technical retention bounds, report protection and optional third-party post-analysis.