Supply Chain Security, API & Database Security
BαΊ£o mαΊt Chuα»i cung α»©ng, API & CΖ‘ sα» dα»― liα»u
Software Supply Chain Security
SBOM β Software Bill of Materials
Complete inventory of ALL software components: first-party code + all direct and transitive dependencies. The security value: when a new CVE is announced, SBOM enables instant impact assessment β "Are we affected?"
Go SBOM generation
go list -m all > sbom.txt
Generates all Go module versions. Cross-reference with govulncheck for CVE status.
US Executive Order 14028 (2021)
Requires SBOM for all software sold to US federal government. BSP/SBV may adopt similar requirements for Philippine/Vietnamese fintech.
Dependency Security Controls
-
PIN
Pin exact versions β Go
go.sumcontains SHA-256 hash of each module. Modification = build fails with checksum mismatch. - SCAN govulncheck checks reachable vulnerabilities in Go module graph β not just "does the package have a CVE" but "is the vulnerable function called?"
- SIGN Container images signed with cosign after CI build β verifies image provenance before ArgoCD deploys to production.
- SLSA Supply chain Levels for Software Artifacts β maturity framework (Levels 0β4) for build provenance, hermetic builds, and auditable pipelines.
Real-World Supply Chain Attacks
| Attack | Year | Method | Lesson |
|---|---|---|---|
| SolarWinds | 2020 | Attacker compromised software BUILD PIPELINE β malicious update shipped to 18,000+ customers via legitimate signed update | Secure the build pipeline itself, not just the code |
| Log4Shell (Log4j) | 2021 | Critical RCE in widely-used Java logging library (CVE-2021-44228) β JNDI lookup in log messages | SBOM enables "are we affected?" in minutes, not days |
| XZ Utils Backdoor | 2024 | Attacker gained maintainer trust over years, then planted backdoor in compression library used by OpenSSH | Even trusted maintainers can be compromised; pin by digest |
| Dependency Confusion | 2021+ | Attacker publishes public npm/PyPI package with same name as company's internal private package β package manager fetches public version | Namespace private packages; configure package manager to prefer internal registry |
OWASP API Top 10 β Most Relevant for FinTech Company X
| # | Name | Description | Platform C / FinTech Company X Example |
|---|---|---|---|
| API1 | BOLA Broken Object Level Auth |
Access another user's resource by changing object ID in the request | Customer A accesses Customer B's loan by changing loan_id=456 to loan_id=789 in API call |
| API2 | Broken Authentication | Weak authentication β missing token validation, exposed credentials, broken token refresh | Unprotected internal API endpoint accessible without auth token |
| API3 | Broken Object Property Level Auth | API returns excess data fields that the caller shouldn't see β over-exposure | Returning full credit score object (including internal scoring factors) when caller only needs approve/reject decision |
| API4 | Unrestricted Resource Consumption | No rate limiting β DoS via exhausting API quota or compute resources | OTP endpoint without 5/hour limit β attacker enumerates all phone numbers, floods SMS gateway |
| API5 | BFLA Broken Function Level Auth |
Regular user accesses admin-level function by calling privileged API endpoint | Customer calling GET /admin/loans β endpoint not protected by role check, returns all customers' loans |
| API6 | Unrestricted Access to Sensitive Business Flows | Business logic abuse β attacking valid API flows at scale | Requesting unlimited OTPs to enumerate valid phone numbers in Platform C's customer database |
BOLA Prevention (Most Critical)
Every loan query must include both tenant AND user ownership checks:
WHERE tenant_id = $tenantID
AND applicant_id = $currentUserID
-- NEVER trust user-provided loan_id alone
BOLA vs BFLA β Key Distinction
BOLA (API1): Access another user's DATA β horizontal privilege escalation at the object level. "I can read your loan."
BFLA (API5): Access a privileged FUNCTION β vertical privilege escalation. "I can call the admin loan approval function."
Database Security: Aggregation, Inference & Polyinstantiation
Aggregation Attack
Combining individually non-sensitive data points to infer sensitive information.
Non-sensitive alone:
Name + Company + DOB + City
Combined = PII sufficient to steal identity β even without SSN or ID number
Inference Attack
Inferring sensitive data from authorized query results.
Example:
"No results returned" for a credit query leaks that the person EXISTS but has poor credit β actionable intelligence even without seeing the actual score
Polyinstantiation
Same primary key exists at multiple classification levels with different values β prevents inference attacks in classified systems.
Example:
employee_id=42 shows "Analyst" to SECRET users; shows "Engineer" to TOP SECRET users β leaking the existence of different data would itself be a security violation
Database Security Controls
| Control | Purpose | Platform C Application |
|---|---|---|
| Database Views | Virtual table that restricts visible columns/rows β different users see different data from the same underlying table | Partner D partner API sees only Partner D tenant's loans via a view β no direct table access |
| Row-Level Security (RLS) | PostgreSQL automatically filters rows based on current user context β transparent to application | FORCE ROW LEVEL SECURITY on all customer-data tables β multi-tenant isolation enforced at DB layer |
| Database Triggers | Automatic action on INSERT/UPDATE/DELETE β can enforce business rules and generate audit records | Audit trigger: every UPDATE to loan_status writes to immutable audit_log table with user, timestamp, old/new value |
| Encryption at Rest | Encrypted data files β compromise of disk or backup doesn't expose plaintext PII | Root cause of TS production incident: missing encryption at rest. Now: AES-256 applied at application layer before write. |
Key Terms
Software Bill of Materials β complete component inventory enabling rapid CVE impact assessment
Supply chain Levels for Software Artifacts β maturity framework (0β4) for build and artifact provenance
Attacker publishes public package with same name as internal private package β mitigation: namespace private packages
Broken Object Level Authorization β horizontal privilege escalation by changing object ID in API request
Broken Function Level Authorization β vertical privilege escalation by calling admin API functions as regular user
Same primary key at multiple classification levels with different values β prevents inference attacks in classified databases
Combining non-sensitive fields to infer sensitive data β mitigation: data minimization, query result limiting
PostgreSQL RLS automatically filters rows based on current user β enforces multi-tenant isolation at DB layer
Inferring sensitive data from patterns in authorized query results (e.g., empty result set reveals information)
- 1. BOLA (API1) = Broken Object Level Authorization = horizontal privilege escalation at the object level. It is the most common API vulnerability. "Customer accesses another customer's data" = BOLA.
- 2. SBOM enables rapid CVE impact assessment β "are we affected by Log4Shell?" answered in minutes with SBOM, days without it. US EO 14028 makes SBOM mandatory for federal software.
- 3. Dependency confusion: attacker publishes to public registry with same name as your private package. Mitigation: namespace your packages (e.g.,
@trustingsocial/pkg-name) and configure package managers to prefer internal registry. - 4. Polyinstantiation prevents INFERENCE attacks in databases β the same primary key has different values at different classification levels. CISSP may present this as a MAC (Mandatory Access Control) database concept.
- 5. BOLA vs BFLA: BOLA = accessing another user's OBJECT (data row) β horizontal. BFLA = accessing a privileged FUNCTION (admin endpoint) β vertical. Both are authorization failures, but at different levels.
(1) Generate SBOM for all Platform C services:
go list -m all > sbom.txt β commit to repo root. Update automatically via CI on every dependency change. When next CVE is announced, cross-reference SBOM instead of manually checking each service.
(2) BOLA prevention β server-side ownership enforcement:
Every loan query must include: WHERE tenant_id = $tenantID AND applicant_id = $currentUserID. Never trust the loan_id from the request URL to scope the query β always re-validate ownership server-side.
(3) Partner D B2B API BOLA check:
Partner D partner API can only query Partner D's own loans. Validate partner_id = 'Partner D' on every Partner D API call β a B2B partner should never be able to query another partner's loan data by guessing loan IDs.
(4) Rate limiting audit:
Verify ALL public Platform C endpoints have rate limiting at Kubernetes-level (nginx-ingress rate limit) or CloudFlare WAF level. Not just the OTP endpoint β all endpoints including KYC initiation, loan application, and partner callbacks.
(5) PostgreSQL RLS verification:
Verify Row-Level Security policies are enabled with FORCE ROW LEVEL SECURITY on all customer-data tables. This prevents a service with elevated DB role from bypassing tenant isolation accidentally.
Root cause reminder: the TS production PII incident was unencrypted data at rest β a code-level failure. RLS + encryption at rest are the two database security controls to verify in every new Platform C service.
Practice Questions
Q1: A customer accesses another customer's loan data by changing loan_id=456 to loan_id=789 in the API URL. Which OWASP API category is this?
Q2: When Log4Shell (Log4j CVE-2021-44228) was announced, how does an SBOM help compared to not having one?
A: With SBOM: query the inventory β "Do any of our services depend on log4j-core?" β answered in minutes. Without SBOM: manually inspect every service's dependency tree, check each config file, and interview each team β takes days, during which the vulnerability may be actively exploited.Q3: Explain a dependency confusion attack and how private package namespacing prevents it.
A: Attacker discovers a company uses an internal package named "aula-utils" (no namespace). Attacker publishes a malicious package named "aula-utils" to the public npm/PyPI registry. Package managers that check public registries first install the attacker's version. Fix: namespace private packages as "@trustingsocial/aula-utils" β public registries don't accept namespaced packages from non-owners.Q4: Give an example of an aggregation attack where no individual field is sensitive but combined they are?
A: In Platform C's database: customer name (public), employer name (from eKYC, semi-public), date of birth (semi-public), home city (from address on file), and loan amount (internal). Each field alone is not highly sensitive. Combined, they uniquely identify a person and reveal their financial status β sufficient for identity theft or targeted fraud without needing their ID number.Q5: What Platform C security requirement does PostgreSQL Row-Level Security enforce, and what does FORCE ROW LEVEL SECURITY add?
WHERE tenant_id=... to every query. FORCE ROW LEVEL SECURITY ensures that even a database superuser role (used by the application with elevated permissions) cannot bypass the policy β tenant isolation holds at ALL privilege levels.
FORCE ROW LEVEL SECURITY, a PostgreSQL table owner or superuser bypasses RLS policies by default β a service using a high-privilege role could inadvertently query cross-tenant data. This is a defense-in-depth measure: even if application-level tenant_id filtering has a bug, the database layer still enforces isolation. This maps to the security principle of defense in depth and least privilege.Domain 8 Complete
You have covered all 5 lessons of Domain 8: Software Development Security β the domain that maps most directly to your daily work as EM at FinTech Company X. SDLC security gates, secure coding in Go/Java, DevSecOps pipelines, STRIDE threat modeling, and supply chain security are all live concerns for Platform C and Platform A.