My name is Emanuel Rukavina. I research the security of software, mostly the kind of software people call "vibe-coded" these days - built fast, often with AI assistance, and rarely looked at closely by anyone with a security background before it ships.
RukaSec is the name of the certificate I issue after doing that kind of assessment. It is not a company, it is not an accredited certification body, and it has no affiliation with any government agency or standards organization (ISO, SOC 2, Common Criteria, or otherwise). It is my own personal, professional opinion, written down and signed.
A RukaSec Certificate is a signed PDF document stating that I, Emanuel Rukavina, tested a specific piece of software, within a specific and clearly stated scope, on a specific date, and recording what I found.
| It IS | It is NOT |
|---|---|
| A point-in-time, scoped, independent opinion | A guarantee that software is "safe" forever |
| A record of what was tested and what was found | An official government or ISO/SOC2 certification |
| Issued with a unique, publicly verifiable Certificate ID | A warranty, insurance policy, or legal indemnity |
| Honest about what was not tested | A claim of zero vulnerabilities, ever |
Every assessment follows a fixed pipeline, adapted per engagement based on scope and access level. The steps below are run in order; later steps depend on what earlier ones turn up.
| # | Phase | Description |
|---|---|---|
| 1 | Scoping & Recon | Define in-scope components, attack surface enumeration (entry points, APIs, auth boundaries, data flows), identify tech stack and dependencies. |
| 2 | Static Analysis (SAST) | Source review where available; automated static scanning for known bad patterns (injection, unsafe deserialization, hardcoded secrets, insecure crypto usage). |
| 3 | Dependency / Supply Chain Audit | Cross-reference all third-party packages and pinned versions against known CVE databases (NVD, OSV, GitHub Advisories). |
| 4 | Dynamic Analysis (DAST) | Runtime testing against a live instance: input fuzzing, auth/session testing, access control (IDOR/BOLA) testing, injection testing. |
| 5 | Manual Verification | Every automated finding is manually reproduced before being included. No scanner output is reported unverified. |
| 6 | Scoring & Reporting | Each confirmed finding is scored (CVSS v3.1), mapped to a CWE ID, and written up with reproduction steps. |
| 7 | Disclosure Window | Vendor/author is given a disclosure period (default 90 days, negotiable) before any public mention, if applicable. |
Note: referencing these standards means they inform the testing approach and scoring. It does not mean the certificate itself is an official certification under any of these frameworks.
Findings are scored using CVSS v3.1 and bucketed as follows:
| Severity | CVSS Range | Typical Meaning |
|---|---|---|
| Critical | 9.0 - 10.0 | Remote code execution, full account takeover, trivially exploitable, no auth required |
| High | 7.0 - 8.9 | Significant data exposure or privilege escalation, exploitable with some constraints |
| Medium | 4.0 - 6.9 | Limited impact, requires specific conditions or user interaction |
| Low | 0.1 - 3.9 | Minimal impact, defense-in-depth / hardening recommendation |
| Informational | N/A | Not a vulnerability on its own; noted for awareness (e.g. verbose error messages, missing security headers) |
Every finding in a full report (the detailed companion document behind each certificate) follows this structure:
| Field | Example |
|---|---|
| Title | SQL Injection in /api/search endpoint |
| CWE | CWE-89 (Improper Neutralization of Special Elements used in an SQL Command) |
| CVSS Vector | AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N |
| CVSS Score | 8.6 (High) |
| Affected Component | File/endpoint path and line number, where applicable |
| Proof of Concept | Minimal reproduction steps or payload |
| Impact | What an attacker gains and under what conditions |
| Remediation | Specific suggested fix |
Every RukaSec certificate has a unique Certificate ID, printed on the document itself. Before trusting a certificate, look it up:
| Part | Meaning |
|---|---|
| RUKASEC | Fixed prefix |
| XXXX (1st block) | Year of issue, e.g. 2026 |
| XXXX (2nd block) | Date of issue, DDMM format, e.g. 1511 for 15 November |
Example: a certificate issued on 15 November 2026 has the ID RUKASEC-2026-1511.
| Step | Action |
|---|---|
| 1 | Find the Certificate ID printed on the document (format RUKASEC-YYYY-DDMM) |
| 2 | Go to certs.rukasec.com/CERTIFICATE-ID.cert Example: certs.rukasec.com/RUKASEC-2026-1511.cert |
| 3 | Compare the record returned against the certificate PDF in hand: subject, scope, date, and findings summary should match exactly |
| 4 | If the ID is not found, or the record does not match the PDF, treat the certificate as unverified |
A certificate whose ID does not resolve at certs.rukasec.com, or whose published record does not match the PDF in hand, should not be trusted as genuine. If a certificate is ever revoked, that status is reflected at its certs.rukasec.com record, even though the original PDF cannot be changed after issuance.
Q: How long does an assessment take?
Depends on scope and access level. A small API or CLI tool: roughly 3-7
working days. A full application: 2-4 weeks. Exact timeline is agreed in
writing before work starts.
Q: Do you need source code access?
Not required, but it speeds things up and generally improves coverage
(white-box vs. black-box). Access level and its effect on scope/cost is
discussed per engagement.
Q: What if you find something critical?
Critical and high-severity findings are reported to you immediately, not
held until the final report - so you can start remediation before the
certificate is even issued.
Q: Can the certificate be revoked after issuance?
Yes. If it later comes out that the issued certificate materially
misrepresented the software's state at assessment time (e.g. the vendor
withheld information that affected scope), I reserve the right to publicly
revoke it.
Q: Is this a penetration test, a code audit, or a bug bounty?
It can combine elements of all three depending on agreed scope. The
certificate and accompanying report make explicit which techniques were
actually applied (see the Methodology table above).
If you would like your software assessed and a RukaSec certificate issued, send an email with the following information:
| Field | What to include |
|---|---|
| Software name & version | Name, version number, and a link to the repository or binary if possible |
| Scope request | What you want tested (e.g. the whole app, a specific API, a specific module) |
| Access | Source code access, a test environment, or credentials, as applicable |
| Deployment context | Language/framework, hosting setup, and whether it's live in production or pre-release |
| Contact info | Your name and a way to reach you |
Send this information to:
I will reply to confirm scope, timeline, and (if applicable) cost before any work begins. No certificate is issued without an agreed scope in writing.