Security
What we check for, and what we found
An extension is code somebody wrote, and code we wrote can be hacked. Nobody can promise you otherwise, so we do the next thing instead: we check our own code against one published list, publish what the check found on every extension, and ship the source readable so you can check it yourself.
What we check for
There is one list and it is published: 45 numbered controls, each written out in our own words rather than a standard's, so it can be read by somebody who has never opened one. Most of them are requirements taken by number from OWASP's Application Security Verification Standard, version 5.0.0. One is ours. It is about a secret a caller hands an extension, a surface that standard does not cover at any level.
We do not claim to be "OWASP Top 10 compliant". That one is a list of risks to be aware of, with no pass condition in it, so there is nothing there to have passed.
What a result means
All 17 extensions on this site have a verdict page of their own: the whole list, that extension's result against every control on it, and four counts that add up to the list.
23 of the controls are machine rules. A rule reads the source text at every site in the code where it could apply, and the row is green only where it found nothing, and it is published with the count of places it looked, because a count of zero says more than a tick does. The other 22 are declared, which is a weaker thing and is meant to be read as one:
"declared is not a pass. It says what a thing is: which routes exist, which values reach a template, where a file gets written. It does not say the thing is fine, and a page of declared rows is not a page of passes." — The security baseline
A declaration still earns its place: one nobody can check is prose, and this one ships beside the code it describes, in a file you can open and disagree with.
Where we come up red
No verdict page here is all green, and none is going to be. Every extension in the repository, including the empty scaffold we test the tooling against, has at least one control it does not meet. The row that says so names the file and the line where it is not met, on an extension you can buy today.
There is no held-back address, no row left out and no state that means red but not in public. That is mechanism rather than nerve: these pages are generated from the source and checked on every build, so leaving a red off one fails the build rather than tidying the page. A verdict page that says more than we can back is itself something we would want reported, and the disclosure scope says so in as many words.
What this does not cover
We check our own code. OpenCart itself and other people's extensions are not ours to verify, and a store runs far more than what we sell it. Your PHP version, your file permissions, your TLS and who has your admin password are yours. And the list is the list: a defect nobody wrote a control for is one the baseline has nothing to say about, which is cheaper to say than to imply the list is exhaustive. No row carries a severity rating either, because what an unmet control costs depends on your store rather than on us.
One more, because it is the one that bites: a verdict describes the source in the repository as it stands. The source runs ahead of the archive you downloaded, so a control reading green today can still be red in the copy installed on your store, until the next release of that extension carries the fix to you.
A review, and something you can re-run
An extension on the OpenCart marketplace is reviewed by the marketplace before it is published, and ours went through that like everybody else's. It is their review, and nothing here restates it or claims it as ours.
What is on this page is a different shape of thing. A review is something we passed. This is something you can re-run: the list is published, the rule behind every machine control is code in the same repository as the extensions, and each extension ships its source readable and unobfuscated. So a result here is one you can reproduce, and disagree with, rather than a badge somebody handed us.
If you have found something
Write to security@kyvero.dev. It is the support inbox under a second name rather than a second team, so a report is not queued behind a question about a date format.
What you get back is written down once, on the documentation, rather than restated here: when we answer, what we ask about publishing, the safe harbour that covers both testing and quoting our source, who the address is open to, and what is in scope.
Reporting a vulnerability: what happens, and what we promise