We cross several analysis engines over your code, your dependencies and your secrets, triage the results by their real exploitability, propose fixes, and only declare a flaw closed when a complete analysis no longer finds it.
Analysis tools produce many results, a large share of them false positives or unreachable flaws. Delivered raw, they discourage teams and hide the few flaws that matter.
So we triage each result by its real exploitability, propose a fix ready for review, and re-check after the merge. A flaw is closed only when the next analysis no longer finds it.
An analysis also says what it did not see. If an engine did not run on a repository, coverage is declared incomplete and nothing there is closed: an absence of alerts is never taken for an absence of flaws.
The analysis goes over your repositories at the agreed pace, weekly by default: each pass shows you only what has changed.
You getAn inventory of results, components and coverage
You getA short, prioritised list
You getFixes ready for review
You getA history of closed flaws
For a manufacturer of a digital product, the security of code and components becomes an obligation; for others, an expectation of the state of the art.
The manufacturer of a product with digital elements must design and develop it in accordance with the essential cybersecurity requirements, and exercise due diligence when integrating third-party components, including open source.12
It reports a component’s vulnerability to whoever maintains it, and handles the vulnerabilities of its product throughout the support period.34
The directive lists security in the acquisition, development and maintenance of systems, including vulnerability handling, among the measures Member States must require of entities.5
The CNIL recommends using secure components recognised by the community, leaving no secret in version control, and running a code review or a non-regression test before each release to production.678
The texts do not apply to every organisation: whether they apply depends on your status, your sector, your size and your contracts. Have it confirmed by your legal counsel or a specialised lawyer.
You choose the level; the scope and deliverables are set by contract.
We analyse your repositories at agreed intervals, weekly by default, and document the flaws found.
DeliverablesWe triage the results and explain, flaw by flaw, the risk and the fix.
DeliverablesWe run the handling of flaws with your teams until the fix is verified, without making the changes in your systems.
DeliverablesStatic analysis suited to each language, secret scanning across history, dependency audits: findings are deduplicated and tracked under one fingerprint from one pass to the next.
Regular passes over every agreed repository, resumable and dated, run on an agreed environment, with automated triage whose every decision is explained.
With the Action Kit option, each flaw retained comes with a proposed fix in your repository, which your developers review and merge.
With the Skill Boost option, your developers qualify and fix real results from their own code, backed by proofs of exploitation, on a staging environment.
The analysis runs on an environment agreed with you, read-only: it does not modify your repositories and does not run your code. The repositories in scope and the data kept are set by contract.
No. An alert on unreachable code or a false positive is documented and closed. We focus effort on exploitable flaws, and keep a record of each decision.
If you are a manufacturer under the CRA, you must exercise due diligence when integrating third-party components, including open source, and report the vulnerabilities you find in them to their maintainer. Have the CRA’s applicability confirmed by your legal counsel or lawyer.23
It is closed only when an analysis in which every engine ran no longer finds it, and we find the commit that closed it. A flaw that disappears because a tool failed stays open.
No. Git history is used to hand each flaw to the right team and repository, not to grade people. Indicators are about repositories and teams.
AI helps us explain flaws and draft fixes; an expert reviews each proposal before it reaches you, and your developers decide on the merge.
For one representative repository, get code, dependency and secret analysis, prioritised findings and actionable remediation guidance for your developers. An initial 30-day engagement tracks changes and rechecks fixes using the available tools. Up to 3 repositories by quote; scans, branches and proposed pull requests are scoped upfront. Your team approves all changes.
Exact text, in its original language, from the frameworks extracted from the official text.
32024R2847-a13-p1When placing a product with digital elements on the market, manufacturers shall ensure that it has been designed, developed and produced in accordance with the essential cybersecurity requirements set out in Part I of Annex I.32024R2847-a13-p5For the purpose of complying with paragraph 1, manufacturers shall exercise due diligence when integrating components sourced from third parties so that those components do not compromise the cybersecurity of the product with digital elements, including when integrating components of free and open-source software that have not been made available on the market in the course of a commercial activity.32024R2847-a13-p6Manufacturers shall, upon identifying a vulnerability in a component, including in an open source-component, which is integrated in the product with digital elements report the vulnerability to the person or entity manufacturing or maintaining the component, and address and remediate the vulnerability in accordance with the vulnerability handling requirements set out in Part II of Annex I. Where manufacturers have developed a software or hardware modification to address the vulnerability in that component, they shall share the relevant code or documentation with the person or entity manufacturing or maintaining the component, where appropriate in a machine-readable format.32024R2847-a13-p8Manufacturers shall ensure, when placing a product with digital elements on the market, and for the support period, that vulnerabilities of that product, including its components, are handled effectively and in accordance with the essential cybersecurity requirements set out in Part II of Annex I. Manufacturers shall determine the support period so that it reflects the length of time during which the product is expected to be in use, taking into account, in particular, reasonable user expectations, the nature of the product, including its intended purpose, as well as relevant Union law determining the lifetime of products with digital elements. When determining the support period, manufacturers may also take into account the support periods of products with digital elements offering a similar functionality placed on the market by other manufacturers, the availability of the operating environment, the support periods of integrated components that provide core functions and are sourced from third parties as well as relevant guidance provided by the dedicated administrative cooperation group (ADCO) established pursuant to Article 52(15) and the Commission. The matters to be taken into account in order to determine the support period shall be considered in a manner that ensures proportionality. Without prejudice to the second subparagraph, the support period shall be at least five years. Where the product with digital elements is expected to be in use for less than five years, the support period shall correspond to the expected use time. Taking into account ADCO recommendations as referred to in Article 52(16), the Commission may adopt delegated acts in accordance with Article 61 to supplement this Regulation by specifying the minimum support period for specific product categories where the market surveillance data suggests inadequate support periods. Manufacturers shall include the information that was taken into account to determine the support period of a product with digital elements in the technical documentation as set out in Annex VII. Manufacturers shall have appropriate policies and procedures, including coordinated vulnerability disclosure policies, referred to in Part II, point (5), of Annex I to process and remediate potential vulnerabilities in the product with digital elements reported from internal or external sources.32022L2555-a21-p2-5security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure;F11-PE-02Utiliser des composants (ex. : bibliothèques) et outils sécurisés et reconnus par la communauté.F11-PE-08Veiller à l’absence de secrets (d’authentification ou de chiffrement) lors du dépôt de code dans un outil de gestion de versions (ex. : Git ou svn). Changer les secrets lors du passage en production.F11-PE-09Effectuer un test de non-régression et/ou une revue de code avant tout passage en production d’une mise à jour pour éviter l’apparition de sources de violation de données personnelles.