How we test, and how we write research
The working rules behind every PoCForge (Cyber Security) engagement and research post: how scopes are tested, what counts as evidence, how retests work, where research facts come from, and what we will not claim.
Short answer
Testing is human-led, scoped in writing and run under agreed rules of engagement. A finding is reported only when we can show it, with steps your engineers can reproduce. Fixed findings are retested. Research posts use public primary sources (vendor advisories, CISA and similar), carry dates, say what could not be verified, and never include weaponised exploit steps.
How we test
- Scope in writing. Assets, environments, user roles, test window, exclusions and contacts are agreed in a statement of work before any active testing.
- Rules of engagement. Production safety limits, data-handling rules and stop conditions are written down and followed.
- Manual first, automation where it helps. Scanners and scripts speed up coverage; authorisation, business logic, tenant isolation and attack paths are tested by a person reasoning about your system.
- Proof within agreed limits. We show what an attacker could actually do, stopping at the agreed boundary rather than causing harm.
- Reporting. Each finding has reproduction steps, evidence, business impact, a severity with stated reasoning and a practical fix.
- Retest. In-scope findings you have fixed are retested and their closure status is recorded.
Our evidence standard
- No finding without evidence: request/response pairs, screenshots or command output, with sensitive data masked.
- Scanner output is a lead, not a finding, until a tester has confirmed it.
- Severity reflects exploitability and impact in your context, and we explain the reasoning.
- When a lighter scan is enough, we say so.
How research is written
- Sources. Vendor advisories, CISA KEV entries and other primary sources first; reputable reporting second. Every research post ends with a Sources section.
- No exploit recipes. We publish affected versions, fixes, mitigations, detection ideas and compromise indicators that are already public. We do not publish weaponised exploit steps.
- Stated limits. If a vendor has not said something (for example, when exploitation began), we say it is unknown rather than guessing.
- No client data. Case studies are anonymised engagement shapes. Client names, logos and identifying details are never published without written permission.
- Organisation authorship. Research is published under PoCForge (Cyber Security) as an organisation, not under personal bylines.
Updates and corrections
Advisories change after publication: new fixed builds, revised scores, new indicators. When that affects a post we update it, and the page’s structured data carries the modified date. Spot an error? Email [email protected] and we will correct it.
Disclosure
If testing turns up a previously unknown vulnerability in a third-party product, we agree the next step with the client and report it to the vendor through coordinated disclosure before publishing anything.
What we don’t claim
- We do not claim CERT-In empanelment. If your procurement requires it, check the official list. See Do you need CERT-In empanelled VAPT?
- No fabricated certifications, client logos, metrics or testimonials.
- No guarantee that a test finds every vulnerability. A penetration test is time-boxed evidence, not a warranty.
Questions people ask
Is your testing manual or automated?
Human-led. Automation is used for coverage and repetitive checks, but findings are confirmed by a tester, and authorisation, logic and attack-path work is manual.
Is a retest included?
Yes. In-scope findings you fix within the agreed window are retested and their closure status is recorded.
Where do research facts come from?
Vendor advisories, CISA and other primary sources, listed in a Sources section at the end of each post.
Do you publish exploit code?
No. Research covers versions, fixes, mitigations and public indicators of compromise, not weaponised exploit steps.
Related
Want this method applied to your scope?
Share the application, environment or requirement and we will propose a test plan before any active work.