Accessibility & WCAG Compliance — Industry Regulations
Difficulty: Intermediate. Regulation: WCAG.
Key Points for Accessibility & WCAG Compliance
- WCAG 2.2 Level AA is the target for most organizations. It covers the POUR principles: Perceivable, Operable, Understandable, Robust
- The ADA applies to websites and apps in the US even without explicit digital accessibility legislation. Court precedent is clear
- The European Accessibility Act (EAA) takes effect June 2025, making digital accessibility a legal requirement across all EU member states
- Automated testing catches roughly 30-40% of accessibility issues. Manual testing with screen readers and keyboard navigation is not optional
- Accessibility fixes are cheapest during design and development. Retrofitting an inaccessible application costs 10-100x more
Common Mistakes with Accessibility & WCAG Compliance
- Adding ARIA attributes everywhere instead of using semantic HTML first. A button element is better than a div with role=button
- Testing only with automated tools like axe-core and assuming the site is accessible because it passes
- Treating accessibility as a separate project or sprint rather than an ongoing quality standard in every feature
- Using color alone to convey information without providing text labels or patterns as alternatives
Related to Accessibility & WCAG Compliance
Privacy by Design, SOC 2 for Engineers
AI Governance & Responsible AI — Operational Governance
Difficulty: Advanced. Regulation: General.
Key Points for AI Governance & Responsible AI
- AI governance is an engineering discipline, not a policy exercise. If your governance framework doesn't integrate into CI/CD, it's theater.
- The EU AI Act classifies AI systems by risk level, with documentation, testing, and human oversight requirements proportional to that risk
- Bias testing must be part of your model evaluation pipeline and must run before every deployment, not once a quarter by a separate team
- Explainability requirements vary by use case. A fraud detection system needs detailed reasoning, a playlist recommender does not.
- Maintain a model risk register that tracks every AI system in production, its risk classification, its data sources, and its last evaluation date
Common Mistakes with AI Governance & Responsible AI
- Treating responsible AI as a checkbox exercise handled entirely by the policy or legal team, with no engineering integration
- Deploying models to production without running bias testing across demographic groups and protected categories
- Assuming open-source models don't need governance because someone else built them. You deploy it, you own the risk.
- Not maintaining a centralized inventory of AI systems in production, making it impossible to respond to regulatory requests
Related to AI Governance & Responsible AI
Privacy by Design, Audit Logging Architecture
Audit Logging Architecture — Operational Governance
Difficulty: Intermediate. Regulation: General.
Key Points for Audit Logging Architecture
- Audit logs answer who did what, to which resource, when, and from where. Every entry must include actor, action, target, timestamp, and source IP
- Immutability is non-negotiable: audit logs must be append-only and tamper-evident to satisfy regulatory requirements
- Separate audit logs from operational logs. They serve different audiences (auditors vs. engineers) and have different retention requirements
- Structured logging with consistent schemas enables efficient querying across millions of events
- Retention periods vary by regulation: SOC 2 requires 1 year, PCI DSS requires 1 year, HIPAA requires 6 years, GDPR has no fixed minimum but expects proportionality
Common Mistakes with Audit Logging Architecture
- Mixing audit logs with application debug logs in the same stream, making audit queries slow and unreliable
- Logging sensitive data (passwords, tokens, PII) in audit entries, which turns audit logs themselves into a compliance liability
- Using mutable storage for audit logs where entries can be modified or deleted by administrators
- Not testing audit log completeness. Running an audit and discovering gaps in coverage is a control failure
Related to Audit Logging Architecture
SOC 2 for Engineers, GDPR & CCPA Data Architecture
Container Security Compliance — Security Compliance
Difficulty: Advanced. Regulation: General.
Key Points for Container Security Compliance
- Image scanning is necessary but not sufficient. Trivy, Snyk Container, and Prisma Cloud catch known CVEs, but runtime security monitoring detects exploitation of unknown vulnerabilities
- Base image selection is a security decision. Distroless images reduce attack surface dramatically compared to full OS images. Alpine is a middle ground
- Kubernetes Pod Security Standards (Baseline, Restricted) replace the deprecated PodSecurityPolicy. Enforce them at the namespace level with admission controllers
- Image signing with Cosign and verification with Sigstore ensures you only deploy images your pipeline actually built. Without this, compromised registries can inject malicious images
- The SLSA framework defines four levels of supply chain integrity. Level 3 (hardened build platform with provenance) is a practical target for most organizations
Common Mistakes with Container Security Compliance
- Scanning images during CI but not blocking deployments when critical vulnerabilities are found. Scan results without enforcement are just noise
- Running containers as root because the application 'needs' it, instead of fixing the underlying permission issue
- Not setting resource limits and security contexts, allowing container escapes or noisy-neighbor resource exhaustion
- Treating Kubernetes network policies as optional, leaving all pod-to-pod communication open by default
Related to Container Security Compliance
Software Supply Chain Security, Zero-Trust Access Governance
Cross-Border Data Transfers — Data Privacy
Difficulty: Expert. Regulation: GDPR.
Key Points for Cross-Border Data Transfers
- After Schrems II invalidated Privacy Shield, Standard Contractual Clauses (SCCs) became the primary legal mechanism for EU-to-US data transfers
- Transfer Impact Assessments (TIAs) are required alongside SCCs to evaluate whether the destination country's laws provide adequate protection
- The EU-US Data Privacy Framework (DPF), adopted July 2023, provides a new adequacy basis for transfers to certified US organizations, but its longevity is uncertain
- Data localization laws are spreading globally. Russia, China, India, Indonesia, and others require certain data to stay within national borders
- Technical measures like encryption with EU-held keys and pseudonymization can supplement legal mechanisms when the destination country's legal framework is inadequate
Common Mistakes with Cross-Border Data Transfers
- Relying solely on the EU-US Data Privacy Framework without a backup plan, given that its predecessor (Privacy Shield) was struck down
- Signing SCCs without performing the required Transfer Impact Assessment for each specific transfer
- Assuming that using a cloud provider with EU regions means no cross-border transfer occurs. Support access, backups, and sub-processors may still involve transfers
Related to Cross-Border Data Transfers
Data Residency & Sovereignty, GDPR & CCPA Data Architecture
Data Classification Frameworks — Data Privacy
Difficulty: Intermediate. Regulation: General.
Key Points for Data Classification Frameworks
- Four classification levels work for most organizations: Public, Internal, Confidential, and Restricted. More levels create confusion without adding meaningful protection
- Classification is only useful if it drives automated policy enforcement. Labels that do not trigger access controls, encryption, or retention rules are just decoration
- Data discovery and classification tools (AWS Macie, Google DLP, Microsoft Purview) can scan structured and unstructured data stores for PII, PHI, and financial data automatically
- Every data store in your organization needs an owner, a classification level, and a documented retention period
- Classification must happen at ingestion time. Retroactively classifying a data lake with three years of untagged data is painful and expensive
Common Mistakes with Data Classification Frameworks
- Creating a classification policy document that nobody references because it does not connect to technical controls
- Classifying data at the system level instead of the field level, leading to entire databases being labeled Confidential when only a few columns contain sensitive data
- Letting engineering teams self-classify without validation, resulting in sensitive data being marked Internal to avoid access control overhead
- Not accounting for derived data and aggregated datasets that may inherit the classification of their source data
Related to Data Classification Frameworks
GDPR & CCPA Data Architecture, Data Residency & Sovereignty
Data Residency & Sovereignty — Data Privacy
Difficulty: Advanced. Regulation: General.
Key Points for Data Residency & Sovereignty
- Data residency is about where data is physically stored; data sovereignty is about which country's laws govern that data. They overlap but are not the same thing
- After Schrems II, transferring EU personal data to the US requires Standard Contractual Clauses plus a Transfer Impact Assessment. Privacy Shield is dead
- China's PIPL requires personal data of Chinese citizens to be stored in China, with a security assessment required before any cross-border transfer
- Not all data needs localization. Classify data by sensitivity and apply residency rules only where regulations actually require it
- CDN edge caches, analytics tools, and backup replication are the three most common ways data accidentally crosses borders
Common Mistakes with Data Residency & Sovereignty
- Assuming that using an EU AWS region means all data stays in the EU. Control plane metadata, DNS queries, and some managed service telemetry may still route through US endpoints
- Forgetting that CDN edge caches replicate content globally by default, which can put personal data in jurisdictions you did not intend
- Using a US-headquartered analytics or logging provider without evaluating whether personal data flows to their US infrastructure
- Building a single-region architecture and trying to bolt on data residency later. Retrofitting geo-partitioned data is an order of magnitude harder than designing for it upfront
Related to Data Residency & Sovereignty
GDPR & CCPA Data Architecture, Privacy by Design
EU AI Act Compliance — Industry Regulations
Difficulty: Expert. Regulation: AI Act.
Key Points for EU AI Act Compliance
- Your PM just told you the EU AI Act applies to your recommendation engine. Before you panic, check Annex III. Most consumer ML features (search ranking, content recommendations, spam filters) land in minimal or limited risk. Recruitment tools, credit scoring, and medical diagnostics are where the heavy compliance hits
- High-risk classification means you need infrastructure most ML teams don't have yet: model registries with lineage tracking, automated bias testing in CI, human-in-the-loop review for low-confidence predictions, and documentation generated from pipeline metadata rather than written by hand
- MLflow, Weights & Biases, and DVC can handle most of the technical documentation requirements if you instrument them early. Retrofitting compliance onto a mature model is 5-10x harder than building it in from the start
- Conformity assessments for most high-risk categories are self-assessed, but biometric systems require third-party audits. Either way, the documentation burden is substantial. Singapore's AI Verify toolkit provides a useful open-source testing framework even if you're not operating in Singapore
- The enforcement timeline is tighter than it looks. Banned practices took effect February 2025. GPAI rules apply from August 2025. Full high-risk requirements hit August 2026. The architectural decisions your team makes this quarter determine how painful compliance will be
Common Mistakes with EU AI Act Compliance
- Assuming 'we only serve EU users through a US entity' exempts you. The AI Act applies to any AI system whose output is used in the EU, regardless of where the provider is based. If your model scores a loan application for an EU resident, you're in scope
- Classifying your system as minimal risk without actually reading Annex III. The annex lists specific high-risk use cases across eight domains, and some are surprising. An AI tool that prioritizes job applications? High-risk. An AI tool that routes customer support tickets? Probably minimal
- Treating compliance as a legal team problem. Legal can interpret the regulation, but engineers have to build the model registry, bias testing pipeline, human override mechanisms, and audit logging. If your engineering team first hears about this six months before the deadline, you're already behind
- Building compliance artifacts manually after model training. If your model card is a Google Doc someone fills out quarterly, it will be incomplete and outdated. Generate documentation from your ML pipeline metadata automatically
Related to EU AI Act Compliance
AI Governance & Responsible AI, LLM Data Privacy & Security
FedRAMP Compliance — Industry Regulations
Difficulty: Expert. Regulation: FedRAMP.
Key Points for FedRAMP Compliance
- FedRAMP Moderate requires 325+ controls from NIST 800-53. Most commercial SaaS companies target Moderate because it covers the majority of federal data types
- The JAB P-ATO path is faster for broad reuse across agencies but harder to get. Agency ATO is easier to initiate but requires a sponsoring agency
- Continuous monitoring is not optional: monthly vulnerability scans, annual penetration tests, and Plan of Action & Milestones (POA&M) reporting
- The System Security Plan (SSP) alone can be 300-700 pages and must precisely describe your authorization boundary
- FedRAMP authorization typically takes 12-18 months and costs $1-3M including tooling, 3PAO assessment, and staff time
Common Mistakes with FedRAMP Compliance
- Underestimating the authorization boundary definition, then discovering mid-audit that a critical dependency is out of scope
- Assuming existing SOC 2 or ISO 27001 compliance covers most FedRAMP requirements. The overlap is maybe 30-40%
- Building the SSP after the system is designed rather than using FedRAMP requirements to inform architecture decisions from the start
Related to FedRAMP Compliance
NIST Cybersecurity Framework, Zero-Trust Access Governance
GDPR & CCPA Data Architecture — Data Privacy
Difficulty: Advanced. Regulation: GDPR.
Key Points for GDPR & CCPA Data Architecture
- Right to erasure requires you to actually find and delete all copies of a user's data, including backups, logs, analytics, and third-party systems
- Consent must be granular, freely given, and withdrawable. A single 'I agree' checkbox is not GDPR-compliant
- Data lineage tracking is essential: you cannot delete what you cannot find
- Retention policies must be enforced automatically, not just documented
- CCPA gives California residents the right to know, delete, and opt out of data sales, with a 45-day response window
Common Mistakes with GDPR & CCPA Data Architecture
- Storing PII in unindexed log files where it cannot be found or deleted for erasure requests
- Treating consent as a one-time event rather than a mutable state that users can change at any time
- Building deletion logic that only removes data from the primary database but not from caches, search indices, or data warehouse
- Not distinguishing between data controller and data processor responsibilities when using third-party services
Related to GDPR & CCPA Data Architecture
Privacy by Design, Audit Logging Architecture
HIPAA Compliance for Engineers — Industry Regulations
Difficulty: Advanced. Regulation: HIPAA.
Key Points for HIPAA Compliance for Engineers
- HIPAA applies to covered entities (hospitals, insurers, clearinghouses) and their business associates. If your SaaS touches PHI, you are a business associate
- Protected Health Information (PHI) includes any individually identifiable health data: diagnoses, treatment records, billing info, even IP addresses if tied to a patient visit
- The Security Rule requires three safeguard categories: administrative, physical, and technical. All three must be addressed
- You need a signed Business Associate Agreement (BAA) with every vendor that can access PHI, including your cloud provider
- Breach notification must happen within 60 days of discovery, and breaches affecting 500+ individuals get reported to media and HHS publicly
Common Mistakes with HIPAA Compliance for Engineers
- Assuming HIPAA only applies to hospitals and insurance companies. Any SaaS product that stores, processes, or transmits PHI on their behalf is a business associate
- Using AWS, GCP, or Azure services that are not HIPAA-eligible and storing PHI in them. Not all cloud services are covered under the provider's BAA
- Treating encryption as the only technical safeguard. HIPAA also requires access controls, audit logging, integrity controls, and transmission security
- Not conducting a formal risk analysis. This is the single most cited HIPAA violation in enforcement actions
Related to HIPAA Compliance for Engineers
PCI DSS Compliance, Audit Logging Architecture, SOC 2 for Engineers
Incident Notification Requirements — Operational Governance
Difficulty: Advanced. Regulation: General.
Key Points for Incident Notification Requirements
- The 72-hour GDPR clock starts when you 'become aware' of the breach, not when you finish investigating. Most teams waste the first 24 hours figuring out who to call, which means you've burned a third of your deadline on coordination overhead
- SEC's 4-business-day disclosure rule (effective December 2023) changed the game for public companies. Materiality determination is now a speed exercise, not a quarterly legal review. Your CISO and General Counsel need a pre-agreed framework for making that call in hours, not weeks
- The operational bottleneck in breach notification is almost never technical. It's getting legal, communications, engineering, and executive leadership aligned on what to say, to whom, and when. Pre-built runbooks with named owners cut this coordination time from days to hours
- If your users span multiple US states, you're dealing with 50+ different notification laws. Florida and Colorado require notification within 30 days. California and New York have enhanced requirements for specific data types. The practical approach: build to the most restrictive requirements and apply them everywhere
- Tabletop exercises reveal the real gaps. Most teams discover during their first drill that their regulatory contact list is outdated, their notification templates haven't been reviewed by current legal counsel, and nobody knows the login credentials for the state AG portal
Common Mistakes with Incident Notification Requirements
- Delaying the investigation to delay the notification clock. Regulators see through this. If your security monitoring detected anomalous behavior on Tuesday and you didn't open an investigation until Friday, the clock started Tuesday
- Having one person who 'knows the process' but nothing documented. That person is on vacation in Iceland with no cell service when the breach happens. Every time. Write the runbook
- Drafting notification letters from scratch during an active incident at 2 AM with a panicking legal team and an impatient CEO on Slack. The quality of those letters is predictably terrible. Pre-draft templates and have them reviewed when everyone is calm
- Treating all security incidents as reportable breaches, or treating none of them as reportable. You need a clear decision framework that distinguishes between 'security event we should investigate' and 'breach that triggers regulatory notification.' The decision criteria should be documented and rehearsed
Related to Incident Notification Requirements
Audit Logging Architecture, GDPR & CCPA Data Architecture
ISO 27001 & ISMS Implementation — Security Compliance
Difficulty: Advanced. Regulation: ISO27001.
Key Points for ISO 27001 & ISMS Implementation
- ISO 27001 is a certification, not an attestation like SOC 2. An accredited auditor verifies your Information Security Management System (ISMS) against a defined standard
- The 2022 revision reorganized Annex A from 114 controls in 14 domains down to 93 controls in 4 themes: Organizational, People, Physical, and Technological
- You do not implement all 93 controls. The Statement of Applicability documents which controls apply to your organization and why any are excluded
- Certification requires two audit stages: Stage 1 reviews your documentation, Stage 2 tests whether you actually do what the docs say
- Surveillance audits happen annually; full recertification every three years. This is not a one-and-done effort
Common Mistakes with ISO 27001 & ISMS Implementation
- Writing an ISMS that describes how you want to operate rather than how you actually operate. Auditors test reality, not aspirations
- Trying to implement all 93 Annex A controls regardless of relevance. The standard explicitly expects you to exclude controls that do not apply
- Treating the risk assessment as a paperwork exercise rather than using it to drive actual security investment decisions
- Underestimating the time between Stage 1 and Stage 2. Most organizations need 2-3 months to close gaps identified in the documentation review
Related to ISO 27001 & ISMS Implementation
SOC 2 for Engineers, Audit Logging Architecture
LLM Data Privacy & Security — Data Privacy
Difficulty: Expert. Regulation: General.
Key Points for LLM Data Privacy & Security
- Every LLM API call is a potential data leak. If you send customer data to a third-party model, you've transferred that data outside your control boundary.
- Prompt injection is the new SQL injection. Untrusted user input mixed with system prompts creates the same class of vulnerability that plagued web apps for decades.
- Data retention policies vary wildly by LLM provider. Some retain prompts for 30 days, some indefinitely. Read the terms before sending any data.
- PII detection and redaction must happen before data reaches the LLM, not after. Once you send it, you can't un-send it.
- Model outputs can contain memorized training data, including PII from other users or organizations that was present in the training corpus
Common Mistakes with LLM Data Privacy & Security
- Sending raw customer data to LLM APIs without PII stripping. GDPR still applies when the processor is an AI model.
- Not implementing input validation for prompt injection, treating LLM inputs as trusted when they contain user-supplied content
- Assuming enterprise tier agreements automatically prevent the provider from using your data for training. Read the actual DPA.
- Ignoring data residency implications of LLM API calls. If your users are in the EU and the LLM endpoint is in the US, that's a cross-border data transfer.
Related to LLM Data Privacy & Security
GDPR & CCPA Data Architecture, Software Supply Chain Security
NIST Cybersecurity Framework — Security Compliance
Difficulty: Advanced. Regulation: NIST.
Key Points for NIST Cybersecurity Framework
- The five core functions (Identify, Protect, Detect, Respond, Recover) provide a lifecycle view of security, not a checklist
- NIST CSF is a meta-framework that maps to specific standards like ISO 27001, SOC 2, and PCI DSS, making it ideal for organizations juggling multiple compliance requirements
- Implementation tiers (Partial, Risk Informed, Repeatable, Adaptive) describe maturity, not security level. Tier 4 is not always the goal
- NIST CSF 2.0 added Govern as a sixth function, putting risk management strategy and supply chain concerns front and center
- Profiles let you define your target state and compare it against your current state to prioritize gaps
Common Mistakes with NIST Cybersecurity Framework
- Treating NIST CSF as a compliance requirement rather than a voluntary framework for organizing your security program
- Trying to implement all subcategories at once instead of prioritizing based on risk assessment and business context
- Confusing NIST CSF (the framework) with NIST 800-53 (the control catalog). They are related but serve different purposes
- Ignoring the Identify function because it feels less urgent than Protect or Detect, even though it is foundational
Related to NIST Cybersecurity Framework
SOC 2 for Engineers, ISO 27001 & ISMS
Open Source License Governance — Operational Governance
Difficulty: Intermediate. Regulation: General.
Key Points for Open Source License Governance
- Permissive licenses (MIT, Apache 2.0, BSD) allow almost any use. Copyleft licenses (GPL, AGPL) require derivative works to use the same license
- AGPL is the most restrictive common license: providing software as a network service triggers the copyleft obligation, catching many SaaS companies off guard
- SBOM (Software Bill of Materials) generation is now required by US Executive Order 14028 for software sold to federal agencies
- License compliance is not just about direct dependencies. Transitive dependencies can pull in GPL or AGPL code without your team realizing it
- BSL (Business Source License) and SSPL (Server Side Public License) are source-available but not open source. They restrict commercial and competitive use
Common Mistakes with Open Source License Governance
- Assuming MIT-licensed code has zero obligations. MIT still requires including the copyright notice and license text in distributions
- Running license scans only at release time instead of in CI, allowing problematic licenses to enter the codebase quietly
- Ignoring license compatibility when combining libraries. Apache 2.0 is compatible with GPLv3, but GPLv2-only is not compatible with Apache 2.0
Related to Open Source License Governance
Software Supply Chain Security, SOC 2 for Engineers
PCI DSS Compliance — Industry Regulations
Difficulty: Advanced. Regulation: PCI.
Key Points for PCI DSS Compliance
- PCI DSS has 12 requirements organized into 6 goals. The core principle is to minimize the systems that touch cardholder data
- Tokenization replaces card numbers with non-sensitive tokens, dramatically reducing your PCI scope
- Network segmentation is the most effective way to shrink your Cardholder Data Environment (CDE)
- SAQ levels range from A (simplest, card-not-present with full outsourcing) to D (most complex, direct card handling)
- PCI DSS v4.0 introduces customized validation as an alternative to prescriptive controls
Common Mistakes with PCI DSS Compliance
- Processing raw card numbers through your own systems when a tokenization provider like Stripe or Braintree could handle it
- Flat network architecture where every server can reach the cardholder data environment
- Storing CVV/CVC codes after authorization, which is explicitly prohibited and an automatic audit failure
- Assuming PCI compliance only matters for large merchants. Even small businesses processing cards must comply
Related to PCI DSS Compliance
SOC 2 for Engineers, Audit Logging Architecture
Privacy by Design — Data Privacy
Difficulty: Advanced. Regulation: General.
Key Points for Privacy by Design
- Privacy by Design means embedding privacy into system architecture from the start, not bolting it on after launch
- Data minimization is the most powerful privacy control. Do not collect data you do not need
- Purpose limitation requires that data collected for one purpose is not repurposed without explicit consent
- Anonymization is irreversible and removes data from GDPR scope entirely; pseudonymization is reversible and data remains in scope
- Privacy impact assessments (PIAs) should be part of the design review process for any feature that handles personal data
Common Mistakes with Privacy by Design
- Collecting all available user data 'just in case' it becomes useful later. This violates data minimization and creates unnecessary risk
- Confusing pseudonymization with anonymization. Hashing an email is pseudonymization (reversible with a lookup table), not anonymization
- Treating privacy as a legal team responsibility instead of an engineering design constraint
- Building analytics pipelines on raw PII when aggregated or anonymized data would serve the same purpose
Related to Privacy by Design
GDPR & CCPA Data Architecture, Software Supply Chain Security
SOC 2 for Engineers — Security Compliance
Difficulty: Intermediate. Regulation: SOC2.
Key Points for SOC 2 for Engineers
- SOC 2 has five Trust Service Criteria: Security, Availability, Processing Integrity, Confidentiality, Privacy
- Type I audits assess design at a point in time; Type II audits assess operating effectiveness over 6-12 months
- Most startups only need Security and Availability criteria to start
- Evidence collection is the hard part, so automate it from day one with tools like Vanta or Drata
- SOC 2 is about proving you do what you say you do, not about being perfect
Common Mistakes with SOC 2 for Engineers
- Treating SOC 2 as a one-time project instead of an ongoing compliance program
- Waiting until the audit to gather evidence instead of automating collection continuously
- Writing policies that describe aspirational practices rather than actual practices
- Ignoring the shared responsibility model for cloud services
Related to SOC 2 for Engineers
Audit Logging Architecture, Privacy by Design
Software Supply Chain Security — Security Compliance
Difficulty: Expert. Regulation: General.
Key Points for Software Supply Chain Security
- An SBOM (Software Bill of Materials) is a machine-readable inventory of every component in your software. It is the foundation of supply chain security
- The SLSA framework defines four levels of supply chain integrity, from basic build provenance (L1) to hermetic, reproducible builds (L4)
- Dependency confusion attacks exploit package managers that check internal registries before public ones. Namespace your internal packages
- Artifact signing with Sigstore/cosign provides cryptographic proof that a container image was built by your CI pipeline
- Log4Shell proved that transitive dependencies are the real threat. You must scan the entire dependency tree, not just direct imports
Common Mistakes with Software Supply Chain Security
- Only scanning direct dependencies and ignoring transitive dependencies where most supply chain vulnerabilities hide
- Generating SBOMs as a one-time exercise instead of producing them automatically with every build
- Trusting container base images without verifying their signatures or scanning them for vulnerabilities
- Not pinning dependency versions, allowing silent updates that could introduce compromised packages
Related to Software Supply Chain Security
SOC 2 for Engineers, PCI DSS Compliance
Third-Party Risk Management — Operational Governance
Difficulty: Advanced. Regulation: General.
Key Points for Third-Party Risk Management
- Vendor security assessments should be proportional to data sensitivity and business criticality. Not every SaaS tool needs a full security review
- SOC 2 Type II reports are the baseline for vendor evaluation, but reading the report matters more than just confirming it exists
- Vendor concentration risk is a real operational threat. If a critical vendor goes down or gets acquired, your recovery plan needs to be more than 'we will figure it out'
- Shadow IT accounts for an estimated 30-40% of enterprise SaaS spending. If you cannot see it, you cannot assess the risk
- Contractual security requirements must be negotiated before signing, not after an incident. Include data handling, breach notification, and right-to-audit clauses
Common Mistakes with Third-Party Risk Management
- Performing vendor assessments at procurement time and never revisiting them, even as the vendor's access scope changes
- Accepting a SOC 2 report without reading the exceptions and management responses
- Failing to maintain an inventory of all third-party integrations, especially those with API access to production data
- Not including security requirements in vendor contracts and having no contractual leverage after a vendor breach
Related to Third-Party Risk Management
Software Supply Chain Security, Zero-Trust Access Governance
Zero Trust & Access Governance — Security Compliance
Difficulty: Advanced. Regulation: General.
Key Points for Zero Trust & Access Governance
- Zero trust means no implicit trust based on network location. Every request is authenticated and authorized, whether it comes from inside the VPN or outside
- RBAC works until you have 500+ roles and nobody knows what they all do; ABAC is flexible but complex to debug; ReBAC (Zanzibar model) handles hierarchical permissions cleanly
- Just-in-time (JIT) access with time-bounded credentials eliminates standing privileges, which are the root cause of most privilege escalation attacks
- Identity-aware proxies (Google IAP, Cloudflare Access, Pomerium) replace VPNs by authenticating every request at the application layer, not the network layer
- Service-to-service auth via mTLS and SPIFFE/SPIRE gives every workload a cryptographic identity, eliminating shared secrets and static API keys
Common Mistakes with Zero Trust & Access Governance
- Calling it zero trust because you added MFA to the VPN. That is still perimeter-based security with an extra factor, not zero trust
- Building a 200-role RBAC system where roles overlap, accumulate, and nobody remembers why half of them exist. Role explosion defeats the purpose of access control
- Granting permanent admin access with a promise to 'review it later.' Standing privileges are the number one cause of excessive access findings in audits
- Implementing mTLS between services but not rotating certificates automatically. Expired or long-lived certs are just shared secrets with extra steps
Related to Zero Trust & Access Governance
SOC 2 for Engineers, Software Supply Chain Security