1. Scope
Weaknesses in code we write, in the dependencies we pull in, and in the infrastructure we run, across every application AppExpertly publishes.
2. Where findings come from
- Code review against the codebase. A full read of every endpoint, guard, signature check and credential path, recorded as a numbered finding list. This is a review rather than a penetration test, and the record says so: nothing is exploited and nothing is attacked. Findings are reasoned from the code, and any claim that can be checked without attacking something is checked, with the evidence quoted.
- Dependency advisories. The lockfile is audited against the advisory database. This has already produced a real result: a high-severity SQL injection advisory against an ORM was found this way and closed, though the code was not exploitable as written.
- Reports from outside. Anyone may report to us. See §7.
- Platform notices from the services our applications integrate with.
3. How findings are rated
Severity weighs what an attacker gains against what they need first. A weakness that yields a customer's credentials but requires an already-privileged position is not the same as one that yields less from nothing.
Two rules apply on top of that:
- Findings are rated in combination, not only alone. Several individually modest weaknesses can compose into a serious one. Where that is the case it is stated on both, because fixing one of a pair and calling it done is the failure this rule exists to prevent.
- A finding that contradicts a rule we set for ourselves is raised, not lowered. It means a control believed to be in place is not.
4. Remediation targets
Measured from confirmation, not from report.
- Critical — fixed within 7 days.
- High — within 30 days.
- Medium — within 90 days.
- Low — next convenient release.
A finding that cannot meet its target is not quietly reclassified to one it can meet. It keeps its severity, and the reason and any compensating measure are recorded against it.
5. Tracking
Every finding is carried as a numbered item with its severity, what an attacker would need first, and its resolution date. Open findings stay listed. A finding closes by being fixed, or by a written decision to accept it. Never by age.
Where a finding is accepted rather than fixed, the record says accepted and says why. Where the fix differs from what was first proposed, the record says what changed.
6. Automated scanning
In progress, and stated as such rather than claimed. Continuous integration currently runs typechecking, build and tests on every change. Automated dependency auditing, static analysis and secret scanning are being added to the same pipeline.
Until that lands, dependency audits run at the point of a dependency change and before a release. The result described in §2 came from exactly that practice.
7. Reporting from outside
Report to dev@appexpertly.com.
- We acknowledge within two business days.
- We give an initial assessment, including a severity, within five business days.
- We tell you when it is fixed.
We will not pursue anyone who reports a genuine finding in good faith and gives us reasonable time to fix it. Please do not access data belonging to anyone other than yourself while testing, and please do not run automated scanning against production.
8. Dependencies
Dependencies are pinned and installed from a committed lockfile, so a build resolves the same tree every time and an advisory can be matched against what is actually deployed. See Infrastructure and Dependency Management.