Vulnerability & Threat Management Policy

This Vulnerability & Threat Management Policy (the "Policy") describes how MyShipPilot LLC ("MyShipPilot", "we") identifies, assesses, prioritizes, remediates and verifies security vulnerabilities and threats affecting the MyShipPilot shipping platform, its dependencies and its integrations. It applies to all personnel, contractors and service accounts that interact with MyShipPilot systems on our behalf.

MyShipPilot is a small company. This Policy deliberately describes only the practices we actually operate. Where an enterprise control is not in place, we say so rather than imply it.

1. Scope

• MyShipPilot application code, server-side functions and public API endpoints.
• Third-party software dependencies used to build and run the platform.
• Platform configuration: authorization rules, database access rules, security headers, rate limits and secrets handling.
• Integrations with payment, carrier and e-commerce platform providers.
• Infrastructure operated for us by managed providers (application hosting and managed database), whose own patching of the underlying platform is their responsibility under their published security practices.

2. Intake and detection sources

We rely on the following sources, all of which exist today:

• External vulnerability reports from customers, merchants, partners and independent security researchers, received through the channels in section 6 and published in our machine-readable security.txt record (RFC 9116).
• Dependency vulnerability scanning of our declared package manifest and lockfile against public advisory data, run as part of our development workflow and before material releases, and re-run when a dependency issue is reported to us.
• Automated backend security review of database access rules and configuration, used to detect missing or over-permissive data access policies.
• Automated test suite executed on changes, including tests that specifically lock security behaviour: administrative route gating must fail closed, privileged server functions must re-check role, security headers must be present, and sensitive endpoints must remain rate limited.
• Operational signals from the running platform: server-side error logging, durable alerts on payment, label and refund failures, a privileged-access log for reads of protected data, an append-only fraud and risk decision trail, inbound webhook processing records, and authentication throttling records.
• Provider notices from our payment, carrier, e-commerce platform and infrastructure providers, including integration deprecations and security bulletins.
• Change review: security-relevant changes are reviewed before release by the individual responsible for the platform, together with the automated checks above.

3. Preventive and threat-mitigation controls

Threat management is not only reactive. The following controls are implemented in the platform and are verified by automated tests:

• HTTPS everywhere, HTTP Strict Transport Security, an enforced Content Security Policy and additional hardening response headers.
• Server-side, role-based authorization on every administrative function, so navigating to an administrative URL alone never grants access.
• Row-level database access rules that isolate each account's data.
• Multi-factor authentication for privileged administrative access and step-up verification for sensitive administrative actions.
• Rate limiting and throttling on authentication and other sensitive or cost-bearing endpoints, applied by account and by network address.
• Cryptographic signature verification on inbound webhooks, with flood protection on public endpoints.
• Secrets and credentials held only in server-side configuration, never shipped to the browser; especially sensitive stored tokens are additionally encrypted by the application.
• Fraud and abuse controls on label purchasing, refunds and carrier billing adjustments.

See our Access Control & Least Privilege Policy and Data Classification & Encryption Policy for detail on those control areas.

4. Assessment and prioritization

Each reported or detected issue is triaged by the individual responsible for platform security. Triage confirms whether the issue is real and reachable in our deployed configuration, then assigns a risk level based on:

• whether personal data, credentials or funds are exposed or at risk;
• whether authentication or authorization can be bypassed;
• whether the affected code path is actually reachable in production and by whom;
• whether exploitation requires privileged access or is available to any anonymous caller;
• availability impact on shipping, payment or tracking flows;
• whether a fix, mitigation or configuration change is available.

Because we are a small organization, we operate risk-based prioritization rather than fixed contractual remediation deadlines. We do not publish or commit to remediation service levels. In practice, issues that expose customer data, credentials or funds, or that allow authentication or authorization bypass, are treated as the highest priority and worked immediately and continuously until contained; issues with no demonstrated reachable impact are scheduled into ordinary development work. Where a fix cannot be applied immediately, we apply a compensating mitigation first — for example disabling the affected feature or endpoint, tightening an access rule, or adding a rate limit — and record the residual risk.

5. Remediation, verification and closure

• Contain — where an issue is live and exploitable, reduce exposure before analysis is complete.
• Fix the class, not the instance — correct the vulnerable code or configuration and check sibling code paths that share the same assumption.
• Add a regression test — security fixes are accompanied by automated tests that fail if the control is later removed, so the fix is durable.
• Verify — the automated suite and a live check of core flows (rating, label purchase, refund, tracking) must pass before the change is released.
• Confirm and close — we confirm the originally reported condition can no longer be reproduced, then close the item and, where a reporter is involved, inform them.
• Escalate to incident response — if a vulnerability shows that protected data was actually accessed without authorization, it is handled under our Security Incident Response Policy, including its notification obligations.

6. Third-party and dependency issues

Third-party components are kept current as part of ordinary maintenance. When a dependency advisory is identified, we assess whether the vulnerable code path is actually used by MyShipPilot, then upgrade the package and regenerate the lockfile, or remove or replace the dependency where no fixed version exists. Fixes are validated by the automated test suite before release. Vulnerabilities in the underlying managed hosting and database platforms are remediated by those providers; we apply any configuration changes they require on our side and monitor their security notices. We limit third-party and service-account access to what each integration requires.

7. Reporting channels

We welcome good-faith vulnerability reports and will not pursue action against researchers who report responsibly, avoid accessing or modifying other users' data, and give us reasonable time to remediate before public disclosure.

• security@myshippilot.com — vulnerability reports and security concerns (preferred).
• privacy@myshippilot.com — personal-data and privacy matters.
• Our contact form for general reports.
• Our security.txt record, which is the authoritative machine-readable contact source.

Please include enough detail to reproduce the issue. Do not include another person's personal data in a report.

8. Roles and responsibilities

• Security owner — receives and triages reports, assigns risk, decides prioritization and approves closure.
• Technical responder — reproduces the issue, implements the fix or mitigation, adds regression coverage and verifies the release.
• Communications — responds to the reporter and, where required, to affected merchants, customers, providers or regulators.

As a small organization, one individual — currently the founder, who also serves as administrator — may perform more than one of these roles, and in a single-operator situation performs all of them. The roles are stated separately so that no responsibility is skipped simply because the same person carries it.

9. What we do not currently operate

For accuracy and to avoid overstating our posture: we do not operate a security operations center, 24/7 staffed monitoring or on-call rotation, a SIEM platform, network intrusion detection or prevention appliances, a recurring third-party penetration testing program, a formal bug bounty with monetary rewards, or a contracted external incident-response retainer. We hold no security certification and do not claim one. We do not publish fixed remediation service levels; prioritization is risk-based as described in section 4.

10. Policy owner and review

This Policy is owned by MyShipPilot LLC. It is effective as of the date shown above and is reviewed at least annually and following material changes to our security posture, architecture or providers, and after any significant vulnerability or incident. Material changes are reflected by updating the "Effective date" shown above.

11. Contact

To report a vulnerability, email security@myshippilot.com.

This Policy is a governance statement and does not modify our Terms of Service. In the event of a conflict, the Terms of Service control with respect to your use of the Service.