Posture Shares

Prove your security posture to a third party without giving them portal access.

A Posture Share is a tokenized, password-protected, time-limited snapshot of your WASViking^® security posture, accessible at posture.wasviking.com. The pattern is the same as the SBOM Evidence Bundle: zero-knowledge share, full access log for the owner, revocable any time.

What recipients see

For the portal walkthrough with screenshots, see Posture Shares in Getting Started.

A Posture Share renders a signed, aggregated report. It never opens a window into the portal.

There is a page written for the person who receives the link: send them the Assessor guide together with the URL. It covers how to open the share, where each question of a vendor assessment is answered, how to verify a signed version and what to file.

The recipient works in a dedicated, read-only space organized in areas, so a vendor assessment can be followed over time instead of read once:

Every area loads with the page. Moving between them is not another view of the link: it never counts against Maximum views and never adds lines to your access log. What each area shows still follows the disclosure level and the sections you chose:

• Posture Score (0 to 100) with last assessment date and the 90-day trend in points (improving, declining or stable). Without a baseline yet, the report says so instead of showing a change of zero.
• Why this score: the exact points each term of the formula takes from 100, so the number can be audited without reading the methodology.
• Posture trend: two views rebuilt from earlier signed snapshots. The last 90 days, week by week, open by default with 90-day / 30-day / today cards: they show how the organization is behaving now. The last 12 months, month by month, add the best and the lowest score of the period and show whether an improvement lasted. The PDF prints the 90-day view. Nothing is recomputed after the fact.
• Framework correlation indicators (PCI DSS, LGPD, GDPR, SOC 2, ISO 27001): the mapped findings split into remediated, accepted and open. A treatment picture, never a certification status.
• Assessments executed: what ran, when and how often, from the platform's own run history. One row per assessment type in scope with the last execution, the cadence (recurring schedule, continuous, with every build, or on demand), the next execution when one is scheduled and the executions completed in the last 90 days, plus a 12 month strip of the months with an assessment. Counts of executions and dates only, never an asset. A continuous source has to prove it: without evidence in the last 30 days it reads "No recent execution", never "Continuous".
• Control evidence by theme: the same signed figures regrouped the way a vendor assessment asks (vulnerability management, secure development, access control, cryptography in transit, data exposure, components and patching, secure configuration, risk acceptance, remediation timeliness), each theme next to the requirement it relates to in each framework. A finding category belongs to one theme only, so nothing is counted twice. The references are a technical correlation: they never state that a requirement is met. NIST CSF 2.0, CIS Controls v8 and the Brazilian central bank rules (Resolution CMN 4.893/2021 and Resolution BCB 85/2021) are cited next to each theme as references only, with no indicator bar of their own. Figures follow the disclosure level of the link.
• Evidence rules: how a figure earns its place. Everything is measured by the platform; a remediated finding that a later assessment detects again is reopened automatically; an accepted risk is a decision, not a fix; a false positive never counts as remediated.
• Assessment statement: a one page signed PDF stating what was assessed, when and by whom, with the score at signing and the full verification link. Made to be attached to a vendor assessment. It is not a certification, an audit opinion or a statement of compliance, and it only exists once at least one assessment was executed in the scope.
• Treatment history (Standard level and above): month by month, what the last version signed in that month said about the findings: open (with critical and high apart), formally accepted and remediated. Nothing is recomputed after the fact.
• CSV exports: current metrics (one figure per row, with a stable key and a label in the language of the link), score and treatment history (weekly over 90 days, monthly over 12 months; the finding counts stay empty below the Standard level) and signed versions with their full verification links. They come from the same gate as the page, so a file never carries a figure the link does not show. Text cells are neutralized against spreadsheet formulas, and a Portuguese link uses the semicolon separator its spreadsheets expect. Every export is recorded in your access log with its hash.
• Remediation plan (Standard level and above): deadlines you declare on the Remediation plan page, next to Posture Shares. You pick a scope, a target (the open findings of one severity or of one control theme) and a due date. The date is the only thing declared in a Posture Share and it is labelled as declared; everything else is measured. The commitment covers the findings open when it was declared, so new findings never move the goalposts, and the recipient sees how many were remediated, formally accepted or remain open, and whether it was delivered before or after the due date. A commitment is never edited: you withdraw it and declare another, and the withdrawn one stays visible for 90 days. Whoever declared it gets an email 7 days and 1 day before the due date and the day after it is missed, each one once, so you never learn about an overdue commitment from your recipient. A returning recipient sees new commitments and status changes in the "changed since your last visit" notice.
• Findings register (optional section, off by default, Standard level and above): the findings one by one, for a reviewer who has to follow each item. A row carries the finding type, severity, status, first seen, last change, age, SLA state and whether a declared deadline still running covers it. It never carries what locates or reproduces a finding: no asset, address, URL, parameter, package, CVE identifier or evidence, and not the title the finding has in your portal. Open and most severe first, limited to 200 rows, with its own CSV export. A recipient can ask for it from the shared space; the decision is yours.
• Ask for a remediation deadline (Standard level and above): when findings are open with no declared deadline, the recipient can ask for one from the shared space. They tick severities from a fixed list (only the ones the link shows as open and that no running commitment covers), there is no free text, and one request a day is accepted. You get an email and the request shows as pending on the Remediation plan page. Nothing changes until you decide: declaring a commitment for that scope and severity answers it, and the recipient sees the new deadline in the "changed since your last visit" notice.
• Responsiveness (Standard level and above): whether somebody picks up what the assessments find. The share of open findings that carry a decision (in progress in the platform, or inside the baseline of a commitment still within its due date; an overdue commitment does not count), the same for critical and high, the open findings waiting more than 30 days with no decision, and the median time to the first response over the findings first seen in the last 90 days. Measured from the finding lifecycle and its status trail, never declared.
• Ask for more detail: the recipient ticks what they need from a fixed list (there is no free text) and you get an email. Nothing changes on the link: the request shows as pending on the link's Details page, saving a new disclosure answers it, and one request a day is accepted.
• Asset coverage.
• At the Standard level: open findings by severity, issue categories with OWASP mapping, and 30-day activity, with remediation and acceptance always shown apart.
• Risk treatment: open, formally accepted and remediated findings by severity. Accepting a risk is a decision, not a fix: it leaves the score but never leaves the report.
• At the Detailed level: remediation performance over the last 90 days (median time to remediate, SLA percentages).
• Assessment coverage per surface (with the Security domains, Infrastructure and Cloud Security sections): how much of each surface the figures stand for, how many surfaces have a gap, and the risk of what is not covered. In a domain report the assets and the targets counted are the domain's own, so a domain whose targets were not assessed in the last 30 days shows that gap instead of reading as fully covered.
• Evidence origin on every domain figure: externally observed, agent verified, cloud account verified, pipeline verified, repository verified, or application package analyzed. No figure in the report is self-attested.
• Optional sections chosen per link: Security domains (Application Security and External Exposure, each with its own index), Infrastructure (fleet index, patch currency, configuration hardening, as fleet-level percentages only), Cloud Security (cloud posture index, coverage confidence and active attack paths, as estate-level figures only) and Active security controls (state only).
• A Methodology & Scope Statement that says exactly what was assessed, how each figure is computed, and what the report is not.

Recipients never see:

• Hosts, URLs, payloads, packages or CVE identifiers.
• Any single finding, unless you turn the Findings register on for that link. Even then a finding shows only as its type, severity, status and dates.
• The size of your fleet or the list of your targets.
• Raw HTTP evidence.
• Your audit log or anything outside the chosen scope.

A domain that was never assessed reads "Not assessed"; it is never shown as clean.

How sharing works

1. Operator scopes the share. Pick the domain scope (or the whole organization), the exposure level, and which sections to include.
2. WASViking builds the snapshot. Point-in-time rebuild, signed.
3. WASViking tells each recipient where to sign in. The operator enters one or more recipient addresses. Each one gets the address of the assessor portal and, when it never signed in, a temporary password. There is no URL or password for the operator to copy or pass on.
4. Recipient signs in at posture.wasviking.com. The temporary password shows nothing of the vendor: it leads to the pages where the recipient creates a free account, a password of their own and the mandatory second factor. Then the shared space opens from My vendors.
5. Bilateral audit log records every access.

Operator controls

Who can do what follows the role. View opens the links, their access log, the snapshots and the remediation plan; manage creates, revokes, extends, re-emits and changes what a link discloses; commit declares or withdraws a remediation commitment, kept apart because it is a dated promise to a third party. Admin and Manager hold the three; Analyst and ReadOnly hold view.

Every action is recorded in the lifecycle audit of the link, next to its access log. A disclosure or scope change keeps the previous and the new setting, so what a recipient could see on a given day stays answerable, and the access log records which domain each view and each PDF download served.

A link that shares several domains offers two downloads: the PDF of the domain on screen, tied to a single signed snapshot, and a consolidated PDF that binds the report of every shared domain behind a summary cover. The consolidated document adds nothing up: each domain keeps its own score, its own signature and its own verification link, and the access log records the download with the snapshot version of every domain in it. Both are visible to the operator on the details page of the link, and the access log can be exported as CSV. The recipient sees neither of them.

Assessment requests

A customer that assesses you does not have to wait for your invitation: from the WASViking Assessor Portal it can ask for your security posture by typing your domain. Posture Shares, Assessment requests is where those requests arrive.

• Only through a domain you proved. A request reaches you only when you proved that exact domain by DNS: Get the DNS record shows a TXT record to publish at _wasviking-posture.<domain> (your domain), and Check now asks the DNS. A domain somebody merely typed routes nothing, so nobody can receive a request, and be assessed, in your place. Domains you already proved for Exposure Intelligence count too. The record is asked again every day and the proof ends when it is gone three days in a row; a sub domain is another domain.
• Who can ask. Only the owner or an admin of an assessor organization that itself proved a domain by DNS. You read that proven domain, the name the organization gave itself, the e-mail of whoever asked, a purpose from a fixed list and an optional short reference. There is no free text. WASViking verifies the domain, never the name an organization gives itself: read the domain letter by letter and approve only a customer you know.
• The requester never learns whether you use WASViking. It reads the same answer for every domain, after the same time, and nothing is e-mailed at that moment. Its request reads as waiting until it expires after 30 days, unless you approve. Decline, Block and Stop taking requests are all silent.
• Approving is creating a link. Approve: create a link opens the usual form with that organization as the recipient. You choose the disclosure level, the domains and the expiry, as for any other link; nothing is shared before that. The organization's owner and admins are told and its members open your shared space, each with their own sign in, and your access timeline names the person behind every visit.
• Request code. Proving a domain takes a DNS change. When that is slow for you, Create a request code gives you a code in the form VR-XXXX-XXXX-XXXX-XXXX that you can publish on your security page or in a questionnaire: a customer types it instead of your domain and the request reaches you. Publishing it is your own choice to say that you use WASViking. It shares nothing, a code nobody has gets the same answer as any other request (codes cannot be probed), and Replace the code or Stop using a code end the current one at once.
• How you are told. One e-mail a day at most, to the people who can manage Posture Shares, with how many requests wait and the proven domains of who asked. It never carries a name somebody chose, and no link to click.
• Permissions. Reading the page needs view; answering, the domains and the switch need manage.

When to use a Posture Share

• Sales motion. A prospect's security team asks "show us your posture." A Posture Share is faster than a SOC 2 report attempt and fresher than a stale PDF.
• Vendor due diligence. Same use case, opposite direction; respond to a vendor questionnaire with a live snapshot.
• Investor diligence. Demonstrate operational security maturity without exposing the operating console.
• Auditor handoff. Pair with the SBOM Evidence Bundle for the full-coverage audit package.

When NOT to use it

• For deep operator collaboration. Add the operator as a Read-only user in your org instead; they get the live portal, scoped by RBAC.
• For high-frequency status updates to a team you already trust. Use a webhook into their Slack instead.

Automation

Posture Shares are created and managed in the portal. There is no public API for them today, and share events are not part of the webhook catalog. What each link can do on its own is notify you by email: on the first view, on an unusual volume of accesses, and when repeated wrong passwords end a recipient's access.

Security properties

• Tokenized. Share code is opaque, not enumerable.
• One door, one account per person. Recipients sign in at posture.wasviking.com with their e-mail, a password of their own and a mandatory second factor (authenticator app, with backup codes). The temporary password that travels by e-mail is valid for 7 days, only its hash is kept, it shows nothing of the vendor and it is erased once the account exists. Nobody, the owner included, holds a URL or a password of the link itself.
• Time-limited. Expiration is chosen at creation, from 1 hour to 90 days (7 days is the default). It can be extended or renewed, but never to more than 180 days ahead: a link only stays open for long because its owner keeps deciding that it should, and each decision is audited.
• Revocable. One-click revoke; effect is immediate.
• Audited. Every access, failed password attempt and PDF download is logged with its time and IP address, and is visible to the operator. The recipient sees none of it.
• Brute-force resistant. Repeated wrong temporary passwords lock that invitation for a while, and continued attempts end it until the owner sends a new one; an account locks itself the same way. The other recipients are not affected, and the sign in page answers every refusal the same way and at the same cost. Every answer of the public host takes a uniform minimum time, so a wrong link and a wrong password look the same from outside. Every password entry, on the report and on the personal password form, also carries an invisible reCAPTCHA check that is verified server side, the same protection as the portal login.

What the recipient gets in their email

One branded message per invited address, sent when you create the link, when you invite someone later and every time you use Resend. It says who shared, gives the address of the assessor portal and tells the recipient to type that address themselves, and to check with their contact, when a message looks unexpected. An address that never signed in also gets a temporary password; one that already has an account gets no password at all.

The temporary password is the one secret that travels by e-mail, which is why it is short lived and nearly useless on its own: it is valid for 7 days, it shows nothing of yours, it only leads to the creation of the account and its second factor, and a new message replaces it. If a message went to the wrong address, moving the invitation ends that password at once. WASViking never stores it in clear and never writes it to a log or to the audit trail.

Every recipient with an account also gets the daily notification described under Invite an assessor, which never says more than your link shows and which they can switch off.