csh/playbook
1
1
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

📦 deps(thirdparty): update snapshots

Browse Source
This commit is contained in:
ci[bot]
2026-06-13 16:02:05 +00:00
parent fc2462186d
commit b4618ee9e9
203 changed files with 11452 additions and 629 deletions
Download Patch File Download Diff File Expand all files Collapse all files
antigravity-awesome-skills/skills/fsi-compliance-checker/SKILL.md
+125
View File
@@ -0,0 +1,125 @@
---
name: fsi-compliance-checker
description: "Maps code, architecture, and infrastructure changes to specific control IDs in PCI-DSS v4.0 and MAS TRM (Singapore financial regulator), producing an audit-traceable findings report with per-control remediation."
category: security
risk: safe
source: community
source_repo: timwukp/agent-skills-best-practice
source_type: community
date_added: "2026-06-12"
author: timwukp
tags: [compliance, pci-dss, mas-trm, fintech, banking, security-review, audit, financial-services]
tools: [claude, cursor, gemini, codex, antigravity]
license: "MIT"
license_source: "https://github.com/timwukp/agent-skills-best-practice/blob/main/LICENSE"
---
# FSI Compliance Checker
## Overview
Maps a concrete change (code diff, architecture design, IaC, pipeline config) to the specific controls it touches in financial services compliance frameworks — PCI-DSS v4.0 for payment card data and MAS TRM for Singapore-regulated institutions — and reports gaps with actionable remediation. This is engineering-level compliance triage: it helps teams catch violations before audit, but it does not replace a qualified assessor (QSA) or the institution's compliance function. Say so in every report.
## When to Use This Skill
- Use when a change touches payment card data (PAN, CVV, track data) and needs a PCI-DSS check
- Use when reviewing changes at a Singapore-regulated financial institution against MAS TRM expectations
- Use when someone asks "is this compliant", "does logging this violate PCI", or requests a banking-regulation review of a diff, design, or Terraform change
- Do NOT use for generic security review (no framework involved), GDPR/SOC2/HIPAA (out of bundled scope), or legal advice
## How It Works
### Step 1: Select the framework
Load only the reference file(s) the engagement needs:
| Situation | Load |
|-----------|------|
| Payment card data is stored, processed, or transmitted | [pci-dss.md](pci-dss.md) |
| Singapore-regulated financial institution (bank, insurer, capital markets, major payment institution) | [mas-trm.md](mas-trm.md) |
| Both apply (e.g. Singapore bank handling cards) | Both files |
| Other jurisdictions/frameworks (SOX, GDPR, HKMA, APRA) | State they are out of scope; offer general secure-engineering review instead |
If the user hasn't said which applies, ask one question: what data does the change touch, and is the institution Singapore-regulated?
### Step 2: Scope the change
Identify what the diff/design actually touches: data elements (card data? customer PII? credentials?), trust boundaries, environments (production? DR?), and third parties.
### Step 3: Assess applicable controls
Select the applicable controls from the loaded reference file(s) — typically 5-15 controls, not the whole framework. List what you ruled out and why (one line each) so the scoping is auditable. Assess each as `Compliant` / `Gap` / `Needs evidence` (can't tell from the artifact — name the evidence required).
### Step 4: Report
Every Gap gets: the control ID, what's wrong in this specific change, concrete remediation, and severity (Critical = violation involving live regulated data; High = control absent; Medium = control partial/undocumented).
```markdown
# Compliance Review: [change title]
**Frameworks:** [PCI-DSS v4.0 / MAS TRM 2021] · **Date:** [YYYY-MM-DD]
**Scope:** [what was reviewed: files, design doc, pipeline]
> Engineering triage only — not a substitute for QSA assessment or the compliance function.
## Data & Boundary Analysis
- Data elements touched: [e.g. PAN (masked), customer NRIC, none]
- Environments/boundaries: [e.g. CDE-adjacent service, public API]
## Findings
| # | Control | Status | Severity | Finding | Remediation |
|---|---------|--------|----------|---------|-------------|
| 1 | [PCI 3.5.1] | Gap | Critical | [specific issue in this change] | [specific fix] |
## Ruled Out (not applicable)
- [Control area] — [one-line reason]
## Evidence Needed
- [Control]: [what artifact would demonstrate compliance]
```
### Step 5: Offer story conversion
Offer to turn findings into backlog items with the control ID in each story for traceability.
## Examples
### Example 1: Logging review
**User**: "Is this PCI-DSS compliant: we log the full request body of card authorization calls for debugging?"
**Skill**: Loads pci-dss.md → Critical findings against 3.3.1 (CVV must never be stored post-authorization — logs are storage), 3.4.1 (PAN display masking), 3.5.1 (PAN unreadable at rest); remediation: remove the log line or apply a field-allowlist redaction filter; flags downstream log-pipeline scoping (10.3.x); QSA disclaimer included.
### Example 2: Cloud migration
**User**: "Our Singapore bank is moving the customer notification service to a cloud region in another country. MAS TRM implications?"
**Skill**: Loads mas-trm.md → reviews against §11.5 (cloud: due diligence, data residency, exit strategy), flags the MAS Outsourcing Guidelines as a related instrument, asks what customer data the service touches before rating severity.
## Common FSI Engineering Triggers
Changes that almost always have compliance impact — check proactively when they appear in a diff:
- Logging statements near payment or authentication flows (PAN/CVV must never be logged; MAS TRM requires security event logging — both directions matter)
- New data stores or caches receiving customer or card data (encryption at rest, retention, residency)
- Authentication/session changes (MFA requirements, session timeout, credential storage)
- New third-party SDKs or API integrations (outsourcing/vendor controls, data flows leaving the boundary)
- Infrastructure changes touching network segmentation, security groups, or public exposure
- CI/CD changes that alter who/what can deploy to production (change management, segregation of duties)
## Guardrails
- Cite control IDs precisely (e.g. "PCI-DSS 8.3.6", "MAS TRM 9.1.1") so findings are traceable in audit tooling; the bundled reference files carry the ID schemes.
- Severity discipline: don't inflate. A missing comment is not a Critical; unencrypted PAN at rest is.
- When the change is compliant, say so affirmatively per control — "no findings" plus the checked-control list is a useful audit artifact.
- Never output real card numbers, even as examples; use the standard test PANs (e.g. 4111 1111 1111 1111) when illustrating.
- Read-only: this skill reviews and reports; it never modifies code, infrastructure, or configuration.
## Limitations
- Covers only the bundled PCI-DSS v4.0 and MAS TRM engineering summaries; other frameworks or local policy overlays need separate review.
- Provides engineering triage, not legal advice, QSA assessment, or formal compliance sign-off.
- Requires concrete evidence such as diffs, designs, IaC, logs, or control artifacts; incomplete evidence should be marked `Needs evidence`.
- The bundled references are concise control maps, not substitutes for reading the official standards.
## Credits
Adapted from [timwukp/agent-skills-best-practice](https://github.com/timwukp/agent-skills-best-practice) (MIT), where the skill ships with evals and a documented 4-layer test methodology (see the repo's TESTING.md).
antigravity-awesome-skills/skills/fsi-compliance-checker/mas-trm.md
+99
View File
@@ -0,0 +1,99 @@
# MAS Technology Risk Management (TRM) Guidelines — Engineering Control Reference
Engineering-relevant expectations from the Monetary Authority of Singapore's TRM Guidelines (January 2021), organized for change triage. Section numbers follow the official guidelines. The TRM Guidelines apply to all MAS-regulated financial institutions; they are principles-based guidelines (not prescriptive rules), so findings should be framed as "expectation gaps", and the institution's own TRM-aligned policies take precedence where stricter.
Related instruments to flag when relevant (not summarized here): MAS Notices on Cyber Hygiene (legally binding baseline), Outsourcing Guidelines, and the MAS AI model risk management information paper for AI/ML systems.
## Contents
1. [Software development & DevOps (§6)](#1-software-development--devops-6)
2. [IT resilience & availability (§8)](#2-it-resilience--availability-8)
3. [Access control (§9)](#3-access-control-9)
4. [Cryptography (§10)](#4-cryptography-10)
5. [Data & infrastructure security (§11)](#5-data--infrastructure-security-11)
6. [Cyber operations & monitoring (§12-13)](#6-cyber-operations--monitoring-12-13)
7. [Online financial services (§14)](#7-online-financial-services-14)
8. [Quick triage table](#8-quick-triage-table)
## 1. Software Development & DevOps (§6)
| Ref | Expectation (summary) | Engineering check |
|-----|----------------------|-------------------|
| 6.1 | Secure-by-design SDLC: security requirements defined at the start, not bolted on | Security stories/threat model exist for the feature |
| 6.2 | Secure coding standards; code review (peer or automated) before deployment | Review gates; standards documented and enforced |
| 6.3 | Source code security: access to repositories controlled; code integrity protected | Repo permissions, branch protection, signed commits where applicable |
| 6.4 | Security testing: vulnerability assessment before production launch and after major changes; penetration testing for internet-facing systems | SAST/DAST in pipeline; pen-test cadence for public systems |
| 6.5 | Separate environments for development, testing, production; production data not used in non-production without protection | Environment isolation; data masking for test data |
| 6.6 | Change management: assessed, tested, approved before production; emergency change procedures with retrospective approval | CI/CD approval gates, change records, rollback plans |
| 6.7 | End-of-life/unsupported software identified and risk-managed | Dependency and runtime version currency |
| — | DevOps note: §6 expectations apply to pipeline automation itself — the pipeline is a production system (access control, audit, segregation of duties in deployment approval) | Who can approve+deploy; pipeline credentials |
## 2. IT Resilience & Availability (§8)
| Ref | Expectation (summary) | Engineering check |
|-----|----------------------|-------------------|
| 8.2 | Availability targets defined; critical systems' RTO ≤ 4 hours and RPO defined per MAS Notice expectations | Architecture supports the institution's stated RTO/RPO |
| 8.3 | Single points of failure identified and addressed for critical systems | Redundancy in new components; multi-AZ/multi-site where critical |
| 8.4 | DR plans tested at least annually; recovery procedures current | New components included in DR runbooks |
| 8.5 | Capacity management: monitor and plan for demand | Load assumptions documented for new services |
## 3. Access Control (§9)
| Ref | Expectation (summary) | Engineering check |
|-----|----------------------|-------------------|
| 9.1 | Least privilege and need-to-have for all access; access reviewed periodically | New roles/permissions minimal; review process covers them |
| 9.2 | Strong authentication for privileged access; MFA expected for critical system administration | Admin paths MFA-protected |
| 9.3 | Privileged access managed: just-in-time where possible, activities logged and reviewed | Break-glass procedures, session recording/audit for admin ops |
| 9.4 | Segregation of duties: no single person develops, approves, and deploys to production unchecked | Pipeline approval separation |
| 9.5 | Remote access secured (MFA, encrypted channels, device posture) | VPN/zero-trust requirements for any new remote path |
## 4. Cryptography (§10)
| Ref | Expectation (summary) | Engineering check |
|-----|----------------------|-------------------|
| 10.1 | Strong, industry-accepted algorithms and key lengths; no deprecated crypto | No MD5/SHA-1 for security, no TLS <1.2, AES-128+ |
| 10.2 | Key lifecycle management: generation, distribution, storage, rotation, revocation, destruction | KMS/HSM usage; no keys in code, config files, or tickets |
| 10.3 | Cryptographic key compromise procedures | Key rotation runbook covers new keys |
## 5. Data & Infrastructure Security (§11)
| Ref | Expectation (summary) | Engineering check |
|-----|----------------------|-------------------|
| 11.1 | Data security throughout lifecycle: at rest, in transit, in use; data loss prevention strategy | Encryption defaults on new stores; egress paths controlled |
| 11.2 | Network security: segmentation, defense in depth; critical systems in secured zones | New services placed in correct zones; no flattening of segmentation |
| 11.3 | Endpoint and server hardening per standards | Base images hardened; IaC matches hardening baselines |
| 11.4 | Virtualization/container security: hypervisor and orchestration hardening | K8s RBAC, pod security, image provenance |
| 11.5 | Cloud: institution remains responsible; due diligence, data residency, exit strategy, and MAS Outsourcing Guidelines apply | New cloud services assessed; data residency for Singapore customer data confirmed |
## 6. Cyber Operations & Monitoring (§12-13)
| Ref | Expectation (summary) | Engineering check |
|-----|----------------------|-------------------|
| 12.1 | Security event logging across systems; logs protected and retained per policy | New components emit security events to central SIEM |
| 12.2 | Continuous monitoring and correlation; anomaly detection for critical systems | Alert rules accompany new security-relevant functionality |
| 13.1 | Cyber incident response plan; roles defined; MAS notification obligations for relevant incidents (as required by notices — commonly understood as within 1 hour for severe incidents) | New failure modes mapped to incident severity matrix |
| 13.2 | Post-incident review and remediation tracking | Incident learnings feed backlog |
## 7. Online Financial Services (§14)
| Ref | Expectation (summary) | Engineering check |
|-----|----------------------|-------------------|
| 14.1 | Strong customer authentication: MFA for login to online financial services and for high-risk transactions | Customer auth flows; step-up auth for transfers/payee changes |
| 14.2 | Transaction signing/confirmation for high-risk transactions; out-of-band notification to customers | Transaction flows notify customers of significant actions |
| 14.3 | Session management: timeout, re-authentication for sensitive actions, protection against hijacking | Session config on customer-facing changes |
| 14.4 | Fraud monitoring and customer education surfaces | New transaction types covered by fraud rules |
| — | Anti-scam expectations (post-2022 MAS/ABS measures): kill switch, cooling-off for new payees/devices, transaction limits | Payment feature changes checked against these measures |
## 8. Quick Triage Table
| Change type | Check first |
|-------------|-------------|
| New feature touching customer money | §14.1-14.2, §6.1, threat model |
| Auth/session change | §9.x, §14.1, §14.3 |
| New data store / data flow | §11.1, §11.5 (residency), §10.1 |
| New cloud service | §11.5 + Outsourcing Guidelines flag |
| CI/CD or repo change | §6.3, §6.6, §9.4 |
| Infra/network change | §11.2, §8.3 |
| New logging/monitoring | §12.1-12.2 |
| Incident-relevant failure mode | §13.1 severity mapping |
| AI/ML model in decisioning | Flag MAS AI information paper review |
antigravity-awesome-skills/skills/fsi-compliance-checker/pci-dss.md
+89
View File
@@ -0,0 +1,89 @@
# PCI-DSS v4.0 — Engineering Control Reference
Engineering-relevant controls from PCI-DSS v4.0, organized by what a code/architecture change typically touches. Control numbers follow the official standard (PCI Security Standards Council). This is a working summary for triage, not the standard itself — for formal scoping consult the full standard and a QSA.
**Key v4.0 dates:** v4.0 became mandatory March 2024; the ~50 future-dated requirements (marked FD below) became mandatory **31 March 2025** — they are now in force.
## Contents
1. [Cardholder data handling (Req 3, 4)](#1-cardholder-data-handling)
2. [Authentication & access (Req 7, 8)](#2-authentication--access)
3. [Secure development (Req 6)](#3-secure-development)
4. [Logging & monitoring (Req 10)](#4-logging--monitoring)
5. [Network & segmentation (Req 1)](#5-network--segmentation)
6. [Payment page / client-side (Req 6.4.3, 11.6.1)](#6-payment-page--client-side)
7. [Quick triage table](#7-quick-triage-table)
## 1. Cardholder Data Handling
| Control | Requirement (summary) | Engineering check |
|---------|----------------------|-------------------|
| 3.2.1 | Account data storage kept to minimum: retention/disposal policies covering all storage locations | New stores/caches must update the data-flow inventory; retention defined |
| 3.3.1 | Don't store sensitive authentication data (CVV/CVC, full track, PIN) after authorization — ever, even encrypted | grep for CVV/CVC fields in models, logs, caches, analytics events |
| 3.4.1 | Mask PAN when displayed (BIN + last 4 max visible) | UI components, receipts, admin screens, support tooling |
| 3.5.1 | Render PAN unreadable anywhere stored (strong crypto, truncation, tokens) | DB columns, backups, object storage, message queues, data lakes |
| 3.6 / 3.7 | Key management: documented procedures, key rotation, split knowledge for manual operations | KMS usage, key rotation schedules, no keys in code/config |
| 4.2.1 | Strong cryptography for PAN over open/public networks; no fallback to insecure versions | TLS 1.2+ enforced, cert validation not disabled, no PAN over email/chat |
## 2. Authentication & Access
| Control | Requirement (summary) | Engineering check |
|---------|----------------------|-------------------|
| 7.2.1 | Access by least privilege, need-to-know, defined roles | New endpoints/services declare required roles; no wildcard IAM |
| 8.3.6 (FD) | Passwords minimum 12 characters with complexity | Password validators, policy configs |
| 8.3.9 | Password change every 90 days OR dynamic risk analysis OR MFA-always | Session/auth design |
| 8.4.2 (FD) | MFA for ALL access into the CDE (not just admins) | Auth flows for any CDE-touching application access |
| 8.6.1-8.6.3 (FD) | Interactive use of system/service accounts restricted; their passwords managed and rotated | Service account credentials in pipelines, cron jobs |
| 8.2.2 | No shared/group accounts except documented exceptional circumstances | Service design, break-glass procedures |
## 3. Secure Development
| Control | Requirement (summary) | Engineering check |
|---------|----------------------|-------------------|
| 6.2.1 | Software developed per secure SDLC, security throughout | Threat modeling, security stories, review gates exist |
| 6.2.4 | Engineering techniques preventing common attack classes (injection, XSS, etc.) | Parameterized queries, output encoding, input validation at boundaries |
| 6.3.1 | Security vulnerabilities identified and ranked (CVSS or equivalent) | Scanner integration, triage workflow |
| 6.3.2 (FD) | Inventory of bespoke and custom software, and third-party components (SBOM-like) | Dependency manifests current; new deps recorded |
| 6.3.3 | Critical/high patches within one month | Dependency update cadence |
| 6.4.1/6.4.2 | Public-facing web apps protected (WAF in blocking mode per 6.4.2 FD) | New public endpoints behind WAF |
| 6.5.1-6.5.6 | Change management: documented, tested, approved; separation of dev/test from prod; no prod data in test; no test accounts/data left in prod before release | CI/CD gates, seed data hygiene, environment separation |
## 4. Logging & Monitoring
| Control | Requirement (summary) | Engineering check |
|---------|----------------------|-------------------|
| 10.2.1 | Audit logs capture: individual user access to cardholder data, admin actions, auth attempts (success/failure), log access, security event types | Audit events emitted for these actions with user identity |
| 10.2.1.2 | All actions by accounts with admin access logged | Admin tooling, support backdoors |
| 10.3.1-10.3.4 | Logs protected from modification, access limited, integrity monitored | Append-only/immutable log storage, restricted access |
| 10.4.1 (FD: automated) | Daily review of security events — automated mechanisms required in v4.0 | Alerting rules exist for new security-relevant events |
| — | **Never log:** full PAN, CVV, passwords, full track data | grep logging statements in payment/auth paths |
## 5. Network & Segmentation
| Control | Requirement (summary) | Engineering check |
|---------|----------------------|-------------------|
| 1.2.5 / 1.2.6 | All services/ports/protocols identified, approved, with security features defined | New listeners/ports documented and justified |
| 1.3.1 / 1.3.2 | Inbound and outbound CDE traffic restricted to necessary only | Security group / firewall changes reviewed against data flows |
| 1.4.4 | Stored cardholder data not directly accessible from untrusted networks | No DB with card data reachable from public subnets |
## 6. Payment Page / Client-Side
The two controls that catch most modern e-commerce teams (both FD, mandatory since 31 Mar 2025):
| Control | Requirement (summary) | Engineering check |
|---------|----------------------|-------------------|
| 6.4.3 | All payment-page scripts: inventoried, authorized, integrity-assured (e.g. SRI/CSP) | Script inventory for checkout pages; CSP headers; no unvetted tags |
| 11.6.1 | Change/tamper detection on payment pages, alerting on unauthorized modification | Monitoring on checkout page headers and script changes |
## 7. Quick Triage Table
| Change type | Check first |
|-------------|-------------|
| New logging | 3.3.1, never-log list (§4) |
| New data store/cache | 3.5.1, 3.2.1, 1.4.4 |
| Auth/session change | 8.3.x, 8.4.2, 10.2.1 |
| New dependency | 6.3.2, 6.3.3 |
| New public endpoint | 6.4.1/6.4.2, 1.2.x |
| Checkout/payment UI | 6.4.3, 11.6.1, 3.4.1 |
| CI/CD change | 6.5.1-6.5.6, 8.6.x |
| Infra/network change | 1.2.x, 1.3.x |