Set a short, checkable baseline: authenticate every request, request least privilege, encrypt traffic, store secrets safely, keep dependencies patched and name a security contact. Publish the fix timelines too. Partners cannot meet a rule they cannot find, and you cannot enforce one you never wrote down.
A real baseline to learn from
Atlassian publishes security requirements for cloud apps on its marketplace, last updated February 2026 at the time of reading. The list is a useful template because it is concrete. Grouped by theme:
| Theme | Requirement in the published list |
|---|---|
| Access | Authenticate and authorize every request on exposed endpoints |
| Data protection | Full disk encryption at rest for stored end user data; TLS 1.2 or higher with HSTS |
| Least privilege | Request only the scopes needed for the intended function |
| Secrets | Do not keep OAuth tokens, API keys or encryption keys in source code, URLs, referer headers or logs |
| Application security | Secure headers and cookies where applicable; validate and sanitize untrusted input |
| Dependencies | No third-party libraries with known critical or high vulnerabilities; no end of life Node.js runtimes |
| Privacy | Do not collect or store credentials belonging to the platform's user accounts |
| Vulnerability management | Follow the bug fix policy, report security incidents, name a security contact |
The page also says partners must address vulnerabilities within stated timeframes in the platform's Security Bug Fix Policy.
Turning a baseline into practice
A list on a web page does not protect anyone. Each line needs an owner, a way to check and a consequence.
- Make requirements testable. "Use TLS 1.2 or higher" can be scanned. "Be secure" cannot.
- Check at submission and later. Run automated checks when a plugin arrives and again on a schedule.
- Define severity and timelines. Say how fast a critical issue must be fixed and what happens if it is not.
- Provide a reporting channel in both directions. Partners report incidents to you, and you report vulnerabilities to partners.
- Match requirements to risk. A plugin that stores customer data off platform needs more than one that only changes local UI. Atlassian's page itself gives separate guidance for apps that send data out of the platform.
- Support partners. The same page invites partners to ask for help implementing a requirement. Fewer rejections come from clearer help than from tougher rules.
Pick the rules that matter most
If you are starting from nothing, begin with three: least privilege scopes, secrets handling and dependency hygiene. They address the most common ways a plugin becomes a route into customer data. Add the rest in waves.
Keep compliance claims honest
If you map partner requirements to a framework, say which requirement supports which control, and do not suggest that a partner is certified because they pass your list. Your baseline is a contract with your partners. It is not an audit report.
Quick check
Should small plugin developers meet the same bar as large ones?
The baseline should be the same for the same risk. Scale effort by what the plugin can reach, not by company size.
How often should partners be re-checked?
Often enough to catch drift: on every new version for automated checks, and on a schedule for the installed base, since new advisories appear after release.
Safeguard helps verify the dependency line item, since SBOM and dependency scanning can show a partner's libraries and policies can fail a build on known high severity issues. Try the free scan.
Sources
Last reviewed: 19 October 2026.
