Security
Reporting a vulnerability
Section titled “Reporting a vulnerability”Please do not open a public issue for a security report.
- Email: security@rakomi.com
- Private vulnerability reporting: the Rakomi JavaScript SDK repository’s advisory form, linked
from its
SECURITY.md.
The Swift package’s own SECURITY.md adopts the terms of the Rakomi JavaScript-family SDK security
policy — response targets, coordinated-disclosure conditions, safe harbor, and how reporter personal
data is handled — so one set of terms governs every Rakomi SDK. A report about the Swift package is
welcome through either channel above; email is the channel that applies without any extra
qualification.
In scope: the RakomiSDK Swift package — its source, its published tagged releases, and the
authentication and credential-handling logic it performs on the device.
Out of scope: the Rakomi platform and the JavaScript-family SDKs (each has its own policy in its own right); third-party dependencies the package pulls in for its own test suite (report those to their maintainers — the package raises its minimum versions when a dependency has a known critical vulnerability). The package carries zero third-party runtime dependencies, so this category does not apply to anything shipped inside your app.
A published version cannot be withdrawn
Section titled “A published version cannot be withdrawn”A Swift Package version is a tag in a source repository; removing a published tag breaks resolution for everyone who pinned it and does not retract anything already fetched. A defect in a published version is corrected by publishing a fixed, higher version together with disclosure — never by withdrawing the defective one.
Threat model
Section titled “Threat model”The SDK secures the parts of the authentication flow under its own control. Several residual risks are outside what a client-side SDK can mitigate on its own, and remain the host app’s or platform’s responsibility:
| Residual risk | Where the responsibility sits |
|---|---|
| A jailbroken device with Keychain-extraction tooling | Consumer apps SHOULD add jailbreak detection. |
| Device passcode bypass | Out of SDK scope. |
| Screen-overlay / clickjacking | Out of SDK scope. |
| Keylogging | Out of SDK scope. |
| App-switcher screenshot leaking sensitive content | Your app’s responsibility — apply a privacy overlay when the app resigns active. |
| MITM on a managed/corporate network intercepting TLS | Mitigated optionally via certificate pinning — see certificateFingerprints in Configuration. |
What the SDK does provide by default: RS256-only token verification (never negotiated from the token itself), PKCE S256-only OAuth with the system browser (never an embedded web view), constant-time comparisons everywhere a secret or signature is compared, and redaction of tokens from every error message and log-facing string. See Session & tokens for the storage and refresh posture, and Errors for the failure taxonomy those mechanisms can surface.
Compliance posture
Section titled “Compliance posture”- Coordinated vulnerability disclosure via
security@rakomi.com, with the process and timelines described above. - Right to erasure:
signOut()clears local state; the SDK’s fresh-install detection clears any Keychain residue left behind by a prior install of the same app. - Privacy by design: non-blocking mount, no telemetry, no token logging by default, and namespaced local storage.
- Supply-chain posture: zero third-party runtime dependencies, so there is no third-party runtime dependency tree to disclose for this package.
- Strong authentication factors: the SDK can carry a TOTP factor (possession) and a biometric factor (inherence) when your Rakomi tenant is configured for factor binding. Whether a given deployment satisfies a specific regulatory strong-authentication or assurance-level standard is a determination for the integrating operator and their own supervisor or auditor — the SDK does not make that determination and certifies nothing on its own.
Supported versions
Section titled “Supported versions”No version of RakomiSDK has been published yet, so no dated support window is running. While the
package is on its 0.x line (Semantic Versioning 2.0.0 §4: “Major version zero is for initial
development. Anything MAY change at any time.”), it carries no dated support window at all — the
same posture every other Rakomi SDK holds on its own 0.x line. A dated support commitment begins
at 1.0.
Next steps
Section titled “Next steps”- Configuration — certificate pinning and every other configuration field.
- Errors — the errors these mechanisms can surface.