PYRONTechly Vulnerability and Patch Management Policy
How Techly finds and fixes weaknesses in Pyron and what it depends on: dependency and code scanning, updates, fix times, accepted exceptions, and how to report a vulnerability.
Purpose
New weaknesses are found in software every day, including in code Pyron depends on and did not write. This policy sets out how Techly Operations Pty Ltd (Techly) finds them, how fast it fixes them, and what it does when a fix is not yet possible.
Scope
Pyron's own code, every library and container image it depends on, its infrastructure code and its cloud configuration.
How weaknesses are found
- Dependencies, on every change. Every pull request is scanned for known vulnerabilities in every dependency, and a change that adds a high or critical advisory cannot merge.
- Dependencies, every day. A daily scan reports every high or critical advisory in what Pyron already runs, because new advisories are published against code that has not changed. Each one is reported to Techly's alerts channel every day until it is fixed or accepted.
- Code and configuration. Every pull request runs static analysis over the files it changes, including security rules for Pyron's code, secret detection, and checks of its infrastructure code, container files and CI workflows. A finding at medium severity or above blocks the change.
- Secrets. GitHub's secret scanning, with push protection, is on for Pyron's repository.
- Container images. Built from base images pinned to an exact digest, and scanned when they are pushed to the registry.
- Cloud configuration. Techly's cloud accounts are scanned against security benchmarks at least once a year, and the findings go on the risk register.
- People. Researchers and customers report what they find (below).
Keeping up to date
- Dependency updates are proposed automatically every week, in pull requests that go through the same checks as any change.
- A new release must be 14 days old before it is proposed, because a malicious release is usually withdrawn within days. A fix for a known vulnerability skips that wait and is proposed at once.
- Container base images are updated the same way.
How fast
| Severity | Fixed, or accepted with a reason, within |
|---|---|
| Critical | 7 days |
| High | 30 days |
| Medium and low | At the next update of that component |
A vulnerability that is being actively exploited, or that exposes Customer Data, is handled as an incident under the Techly Incident Management Policy, whatever its rating.
When a fix is not yet possible
Sometimes no fixed version exists, or the vulnerable code cannot be reached. Then the finding is accepted in writing: why it cannot be fixed, why the risk is acceptable, and an expiry date no more than a few months away. On that date the daily scan reports it again, and the reason is checked once more.
Reporting a vulnerability
Write to security@pyron.io, the address in Pyron's security.txt, or to Teams@techly.au, with enough detail to reproduce it. Techly acknowledges a report within 5 business days and keeps the reporter informed until it is resolved. Clause 10 of the Website Terms sets out what good-faith reporting means. Techly does not run a bug bounty.
Penetration testing
No independent penetration test of Pyron has been done yet.
Who is responsible
- The Technical Director owns this policy, fixes or accepts each finding, and approves every exception.
Review
The Technical Director reviews this policy every year.