Saas security

Skill ShieldNet-360/secure-vibe/dist/agent-skills/.agents/skills/saas-security

SecureVibe — prevention-first security for AI-written code. Signed SKILL.md knowledge that makes AI coding assistants write secure code at generation time, plus a deterministic CI gate. Offline · keyless · Ed25519-signed. By ShieldNet360.

Install

npx -y skills add ShieldNet-360/secure-vibe --skill saas-security

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Detect tokens, misconfigurations, and admin red flags for major SaaS platforms (GWS, Atlassian, Notion, HubSpot, Salesforce, BambooHR, Workday, Odoo, chat platforms, Zoom, Calendly, NetSuite) — Applies to: when wiring a SaaS API key or OAuth token into code; when reviewing a SaaS connector / webhook / SCIM bridge; when triaging suspicious SaaS admin activity; when authoring infrastructure that proxies SaaS traffic; when answering a SaaS-related security question

SKILL.md

7.4 KB, ~1.7k tokens by cl100k_base, as published. Nobody here has run it

SaaS Application Security

Detect tokens, misconfigurations, and admin red flags for major SaaS platforms (GWS, Atlassian, Notion, HubSpot, Salesforce, BambooHR, Workday, Odoo, chat platforms, Zoom, Calendly, NetSuite)

ALWAYS

Store SaaS API tokens, OAuth secrets, webhook signing keys, and service-account JSON files in a secrets manager (Vault, AWS Secrets Manager, GCP Secret Manager, Doppler, 1Password Connect) — never inline, never os.Setenv-from-source, never in CI repo variables (only secrets.*).
For OAuth-based SaaS integrations (Google Workspace, Microsoft 365, Slack, Atlassian Cloud, HubSpot, Zoom, Notion, Lark, Calendly, NetSuite OAuth 2.0, Salesforce Connected Apps): persist refresh_token encrypted-at-rest, refresh access tokens before expiry, and store the client secret in a server-only path (never in JS/mobile bundles).
For HMAC webhook callbacks (Slack X-Slack-Signature, Calendly V2 Calendly-Webhook-Signature, HubSpot v3 X-HubSpot-Signature-v3, Stripe-style platforms, Zoom verification token, Teams outgoing webhook HMAC, Lark X-Lark-Signature, Notion verification token): validate the signature and the timestamp window (default 5 min) on every inbound request before parsing the body or trusting any field.
Pin SaaS API base URLs to the vendor's production hostnames (api.atlassian.com, api.hubapi.com, api.calendly.com, *.zoom.us, slack.com/api, graph.microsoft.com, api.bamboohr.com, wd*.myworkday.com, *.salesforce.com/*.force.com, api.notion.com, open.larksuite.com/open.feishu.cn, *.netsuite.com). Reject responses from unexpected hostnames — this catches DNS-takeover and account-takeover proxy attempts.
Treat SCIM and directory-sync endpoints as security-sensitive: require mutual TLS or signed JWT bearer, rate-limit, and log every user/group write to a tamper-evident sink.
Use least-privilege scopes on every SaaS app you create. Salesforce Connected Apps: avoid full/refresh_token unless required. Slack bot tokens: list only the scopes you call. Google Workspace OAuth: request .../auth/admin.directory.user.readonly instead of admin.directory.user if you don't write. HubSpot Private Apps: tick only the scope checkboxes you actually call.
Enforce 2-step verification (2SV / MFA) on every SaaS admin console, including super-admin / org-owner / billing-owner accounts. Tie SSO to your IdP and disable password fallback for admins.
Require dedicated, non-shared service accounts for system-to-system SaaS integrations. Service account names should encode purpose (jira-ingestion-sa, not api-user-3). Disable interactive login on these accounts where the platform allows.
For Google Workspace specifically: rotate domain-wide delegation service-account keys ≤ 90 days, prefer Workload Identity Federation where supported, and audit Admin SDK calls in Admin Console > Reports.
For Atlassian (Jira/Confluence) specifically: prefer OAuth 2.0 (3LO) / Atlassian Connect with actAsAccountId; only fall back to user-bound API tokens when scripting personal automation. Rotate the per-user API tokens ≤ 90 days.
For NetSuite specifically: prefer OAuth 2.0 or TBA (Token-Based Authentication) with a dedicated integration record; never use the user/password login flow for system integrations.
For BambooHR / Workday / NetSuite (HRIS/ERP class): treat every bulk employee/PII export as a DLP boundary — log the request, the authenticated principal, the row count, and the destination. Alert on unusual volume.

NEVER

Hard-code a SaaS API token, OAuth client secret, webhook signing key, or service-account JSON in source, container images, mobile app binaries, or client-side JS. The vendor token formats this rule file detects (e.g. xoxb-, xapp-, jira_pat_, pat-na, ya29., 1//, sk_live_) are mass-scanned by attackers on public GitHub, npm, PyPI, and Docker Hub within minutes of push.
Disable webhook signature verification "for testing." Every Slack / HubSpot / Zoom / Calendly / Teams / Lark / Notion compromise via spoofed webhook in the public record exploited an integration that shipped to prod with signature checks off.
Issue a Google Workspace super admin OAuth scope (https://www.googleapis.com/auth/admin) to anything other than a tightly-controlled IT-owned automation. Most use cases need only the narrower admin.directory.*.readonly.
Share a single personal API token across services for Jira, Confluence, BambooHR, Workday, NetSuite, or Notion. Person-bound tokens inherit the human's privileges and leak through that human's laptop / SaaS account.
Configure a Slack / Teams / Lark / Google Chat incoming webhook URL that posts into a channel of higher trust than its consumers. If a CI bot can post into #secops, a CI compromise = direct phishing of secops. Use signed apps + per-channel posting permissions instead.
Leave link sharing on Google Drive / Notion / Confluence / Atlassian Cloud / SharePoint at "Anyone with the link" for documents containing customer data, secrets, or non-public roadmaps. Default the org sharing policy to domain-restricted.
Trust the From / email field of a Calendly / HubSpot / Zoom webhook payload as authoritative identity. The signature proves the vendor sent the payload; the body fields can still be attacker- supplied (spoofed invitee, attacker-set custom field). Look up the user by canonical ID server-side.
Forward SaaS OAuth refresh tokens between environments (dev↔staging↔prod) — each environment must have its own connected app / OAuth client, otherwise prod credentials live in dev's blast-radius.
Trust Salesforce Apex / NetSuite SuiteScript / Workday Studio / Jira ScriptRunner code installed by a third party without a security review. These run with elevated privileges and are a recurring vector for SaaS supply-chain incidents (e.g. the Salesforce-via-AppExchange ATO patterns documented by Salesforce Security 2024).

KNOWN FALSE POSITIVES

Vendor-provided sandbox / example tokens in official docs (e.g. Slack xoxb-XXXXXXX-XXXXXXXX, Stripe sk_test_…, Calendly eyJ…example…) — match the regexes but contain literal EXAMPLE / XXX / test markers in the surrounding context.
ghp_… / gho_… in third-party SaaS docs explaining how to wire GitHub into them — these are GitHub tokens, not SaaS-platform tokens, and are covered by secret-detection.
Public service-account email of a published Google Marketplace app (*@gserviceaccount.com) — the email is public; only the JSON key is sensitive.
OAuth client IDs for public mobile / web SPAs — they are designed to be public. The matching client secret must still be private; signal only on the secret.