Application security assessments · Early access

Review the assessment
shared with you.

Received an email from Pensec about your website? Open your dashboard to access an assessment shared with you, understand the evidence, and review the next steps.

Reports include the scope, evidence, supported impact, and recommended changes.

Why did Pensec contact you?

We discover product websites through Product Hunt and other public product and launch sources. Our assessment-led outreach starts with a specific observation, followed by a brief summary for the responsible product owner.

What an assessment contains.

Fictional public-exposure example. The assessment mentioned in your email belongs in your private dashboard.

Pensec / Application assessmentFictional sample report

acme.example: public exposure

Illustrative evidence and reviewer notes
Example scope
Public pages and linked assets on one website. No application login or cross-account testing.
What remains untested
Authenticated roles, tenant boundaries, payments, and other application workflows.
Observation and retest status
Fictional evidence only. No live assessment or deployed retest has been performed.
2Illustrative observations
1Medium priority
1Low priority
Findings 2Select a finding to explore
Medium priorityInformation exposure#02

A production source map is publicly available

A public source map makes application source code and internal paths easier to inspect. This example did not contain credentials.

Keep production source maps private. Upload them directly to your error tracker, remove public copies, and verify that the URL is no longer accessible.

Illustrative reviewer note

Source exposure confirmed. Severity depends on what the map reveals; no credential leak is asserted here.

From an assessment email to your next action.

Start with the report already shared with you. Additional testing is a separate scope conversation.

  1. Open your dashboard

    Sign in with Google or GitHub. Authentication gives you a workspace; report access is confirmed separately.

  2. Find the assessment

    Open Reports and match the website and assessment reference from your email. Reply if access needs resolving.

  3. Inspect the evidence

    Review the observation, demonstrated impact, recommended fix, and limits of the assessment.

  4. Choose the next step

    Investigate the fix with your team, ask a question, or discuss a deployed-fix retest and any deeper assessment.

An assessment read is not permission for further testing. Target, access, methods, timing, and any paid scope are agreed separately.

What your report covers and what remains untested.

Review the named application, collection methods, and coverage limits alongside the findings.

What was observed

The named website, observation date, collection method, and public or authorized scope. Candidates stay distinct from confirmed findings.

Why it matters

The evidence and impact actually supported, with prerequisites and uncertainty. Reviewer notes identify real review when it occurred.

What to do next

A recommended change and criteria for checking it. A deployed retest is an observed outcome, not an assumption that a code merge fixed it.

Need more than the initial assessment?

Signed-in workflows, roles, tenant boundaries, and business logic need their own agreed scope. We can discuss deeper investigation or a defined retest once you’ve reviewed the initial evidence.

Additional scope, agreed with you.

Confirm the application and environment, synthetic accounts, permitted methods, reviewer assignment, report, retest window, and any quote before work.

Discuss another assessment

Recurring checks and GitHub release linkage remain planned, not yet available. Initial shared finding access does not require purchasing further work.

Questions about the email or your assessment?

Start with the website and reference in the message you received.

Why did I receive an email from Pensec?

Our primary outreach is assessment-led: we discover product websites through Product Hunt and other public product sources, review a specific observation, and contact the responsible business owner. A finding-specific email should name your website, the date, and a supported summary. A confirmed vulnerability, a public-exposure observation, and an unconfirmed concern should not be described as the same result.

Where can I see the assessment mentioned in my email?

Open the dashboard at app.pensec.app, sign in with Google or GitHub, and choose Reports. Only assessments shared with your workspace should appear there. Match the website and assessment reference to your email. The homepage report is a fictional example, not your private assessment.

What if I sign in and the assessment is not listed?

Reply to the assessment email with its reference so we can confirm the correct recipient and resolve access. Signing in alone does not establish report entitlement, and Google/GitHub identities are separate. You don’t need to request the same assessment again. An empty list is not a clean security result.

What was tested before you contacted me?

The specific assessment must state its actual collection methods, public or authorized scope, date, and limitations. A public product listing does not authorize unrestricted testing. Authenticated flows, active probing, or deeper investigation require explicit authority and agreed scope. Ask the sender if the scope is unclear.

Do I need to pay to read the shared finding?

No purchase should be required to read the initial finding shared with you. Any deeper assessment or retest is additional work with separately agreed scope, availability, and commercial terms. Reviewing a shared assessment does not create a subscription.

How can I confirm the email and dashboard destination?

You can open app.pensec.app directly and choose Reports after sign-in, rather than relying on an email link. Match the named website and reference, and ask the sender about any mismatch. Pensec does not need your application passwords or tokens by email; access for additional work is agreed separately.

What does a deployed-fix retest establish?

Within the agreed retest window, the proposed workflow identifies the updated environment, replays the original evidence and realistic variants, and checks legitimate functionality. The report records verified closure, a still-reproduced finding, or an inconclusive result. A merged code change alone is not deployed-fix verification.

Does a clean report mean the application is secure?

No. A report is bounded by its scope, configuration, and point in time. It should say what was exercised, what remained untested, and what is uncertain. Failed access or unfinished testing is incomplete coverage, not a clean result.

Access your shared assessment.

Open your dashboard, then Reports. If the emailed assessment isn’t visible, reply to the sender to confirm access.