CHOOSE THE RIGHT LEVEL OF VALIDATION
The right assessment starts with the right question.
Not every potential weakness requires the same method of investigation. Choose a starting point based on what you need to learn, validate, or demonstrate.
01 / VULNERABILITY ASSESSMENT
Identify potential weaknesses across your environment.
Review in-scope systems for known vulnerabilities, exposed services, outdated components, and security configuration issues. Findings establish where further investigation or remediation may be needed; a vulnerability assessment does not, by itself, prove exploitability.
02 / PENETRATION TESTING
Establish which weaknesses can be exploited.
Use controlled, authorized testing to investigate real attack paths through applications, APIs, networks, and infrastructure. Understand how technical weaknesses might affect data, identities, operations, or customer trust.
03 / SECURITY CONFIGURATION REVIEW
Find risk in how systems are deployed.
Examine selected cloud, identity, network, and system configurations for unnecessary exposure, excessive permissions, or missing safeguards. Translate configuration gaps into concrete improvement actions.
04 / REMEDIATION VALIDATION & RETESTING
Confirm that fixes address the original risk.
Reassess agreed findings following remediation to determine whether the reported issue remains reproducible. Make it easier for engineering and security teams to close the loop with evidence rather than assumptions.
WHY CHOOSE CCURITY
Findings are only the beginning.
A useful assessment should make technical risk easier to understand, prioritize, and resolve—not simply add another report to the backlog.
Discuss What Needs Testing
Evidence before conclusions.
We distinguish potential vulnerability indicators from conditions validated through agreed technical testing.
Business context, not just severity scores.
We connect findings to systems, data, user roles, and plausible impact so teams can prioritize effectively.
Clear direction for engineering.
Reports explain the issue, supporting evidence, and practical remediation considerations.
Testing aligned to your environment.
Scope is defined around critical assets, business workflows, available access, and operational constraints.
WHY CHOOSE CCURITY
A structured assessment. Clear decisions at every stage.
Review next steps
Walk through findings and define remediation validation or future testing as appropriate.
Understand the environment
Align on objectives, systems, business priorities, and whether discovery, validation, or independent assurance is needed.
Agree scope and rules
Confirm authorized targets, access, methods, exclusions, contacts, and escalation procedures.
Assess and validate
Apply the agreed methodology to investigate weaknesses and authorized exploitation paths.
Report and prioritize
Explain what was observed, why it matters, and what should be addressed first.
ASSESSMENT SCOPING
What do you need to assess?
Get Assessment Scoping Guidance
Tell us a little about your environment. These details help determine a suitable assessment type and the information needed to build a scoped proposal. This is a scoping guide, not an instant quote or automated security verdict.
What needs reviewing?
Web application / API / Mobile application / External network / Internal network / Cloud environment / Not sure
Main goal
Identify exposure / Validate exploitability / Customer requirement / New release / Remediation
Approximate scope
Applications, APIs, IP ranges, cloud accounts, or environments
Available access
Public only / Test credentials / Internal access / To be discussed
Preferred timeframe
Next 30 days / 1–3 months / Exploring
Contact details
Name · Work email · Company (required; subject to privacy notice)
Confirmation: Thanks for sharing the initial scope. The next step is to review the environment, objectives, and authorization requirements before recommending an assessment.
RELATED INSIGHTS
Vulnerability Assessment vs. Penetration Testing
What does each actually prove? Understand identifying possible weaknesses versus validating exploitability.
What to Expect From a Security Assessment Report
What engineering and security leaders need to act on technical findings.
Approved Case Study
Reserved for a verified, anonymized assessment example. No outcomes are assumed or fabricated.
Clarity before you go further.
Understand what the PHP2Shell Exposure Check covers, what it can establish, and what happens next.
Does using PHP mean our application is vulnerable?
−
+
No. Identifying PHP or a PHP-based framework does not establish whether a deployment is vulnerable. The actual runtime, applicable patches, deployment context and relevant configuration need to be considered.
Is the PHP2Shell Exposure Check a penetration test?
−
+
No. It is a focused, non-intrusive initial review. A penetration test involves a separately agreed scope and additional security testing.
Can you confirm our PHP security status from a public URL alone?
−
+
Not necessarily. Publicly observable information may be incomplete or may not identify the runtime actually processing requests. More reliable verification may require information supplied by your engineering or infrastructure team.
What technical information may be needed?
−
+
Depending on the agreed scope, useful information may include the deployed PHP runtime version, hosting or vendor details, package or patch records, and relevant configuration settings. The information required will be discussed before the review.
Will cCurity test our systems without permission?
−
+
No. The proposed process requires scope and authorisation to be established before technical review or testing activities begin.
Will the check prove that our environment is secure?
−
+
No. The review is limited to agreed PHP2Shell-related considerations. It cannot provide assurance about every application, infrastructure or security weakness.o. A PHP technology signal or version number alone does not establish exposure. The deployed runtime, patch status and relevant configuration need to be considered together.
What happens if further investigation is needed?
−
+
The observations can inform a discussion about the appropriate next step. If more extensive security testing is justified, its objectives, scope and authorisation would be agreed separately.
Should we wait for the exposure check before applying patches?
−
+
No. Organisations should follow applicable PHP and vendor security guidance. The exposure check is not a reason to delay security updates or established incident-response procedures.
Tell us what you're building, securing or preparing to launch. We'll help determine where an offensive-security assessment can create the most value.
Cookie preferences
Choose your cookie preferences. Your choices are saved on this device. Tracking integrations are not yet connected to these controls.