The Telnyx SDK compromise on PyPI presents your security team with a critical decision: do you restrict package installation at the perimeter, or do you allow flexibility and invest in runtime detection?
On March 27, 2026, malicious versions 4.87.1 and 4.87.2 of the Telnyx package appeared on PyPI. The attackers used RSA-4096 public key encryption and AES-256-CBC + RSA OAEP schemes—this was a calculated supply chain attack against a legitimate package.
Your compliance framework likely mandates secure software supply chain practices, but the implementation details matter more than the principle. If you're managing PCI DSS v4.0.1 Requirement 6.3.2 (securing custom software) or SOC 2 Type II CC6.8 (managing changes to system components), you need a concrete answer to this question.
The Decision You're Facing
You have three viable approaches to dependency security:
Allowlist-only repositories: Lock down to pre-approved packages through a private mirror or proxy.
Monitor-and-respond: Use public repositories with runtime detection and integrity verification.
Hybrid gating: Allow public packages but require security review before production use.
Each path satisfies compliance requirements differently and has operational costs your team will feel daily.
Key Factors That Affect Your Choice
Your deployment velocity: How many new dependencies does your team add per sprint? If you're shipping features weekly with evolving dependencies, an allowlist becomes a bottleneck. If you're running stable infrastructure with quarterly updates, restriction is manageable.
Your threat model: Are you protecting payment card data or customer financial records? The Telnyx attack exfiltrated sensitive data across systems—your risk tolerance should match your data classification.
Your team's security maturity: Can your developers verify package signatures? Do they understand how to inspect a dependency's commit history? If you're building that capability, start with restrictions. If you have senior engineers who can evaluate risk, monitoring gives them room to work.
Your compliance scope: ISO 27001 Annex A.8.31 requires you to address supply chain security but doesn't prescribe the method. SOC 2 Type II CC7.2 asks for monitoring of system components. PCI DSS v4.0.1 Requirement 6.3.3 demands that you validate custom code before production. Map your controls to your actual obligations.
Path A: Allowlist-Only Repository (High Control)
Choose this when:
- You operate in a PCI DSS v4.0.1 environment handling cardholder data.
- Your team has fewer than 20 active services with stable dependencies.
- You can staff a security review process with a 48-hour SLA.
- You've experienced a supply chain incident in the past 18 months.
- Your compliance auditor explicitly requires pre-approval of third-party code.
Implementation requirements:
Set up a private PyPI mirror using tools like Artifactory or Nexus. Configure your pip and poetry clients to reject packages not in your mirror. Establish a review workflow: developer requests package → security reviews source and maintainer history → approved packages sync to your mirror.
This satisfies PCI DSS v4.0.1 Requirement 6.3.2 by ensuring all code undergoes review before deployment. It maps to NIST Cybersecurity Framework v2.0 function ID.SC-5 (response and recovery planning for supply chain).
The operational cost: your security team becomes a gatekeeper. When a developer needs a new package for a Friday deployment, your approval process determines whether they ship on time. Budget 4-8 hours per week for package reviews, more during high-velocity periods.
Path B: Monitor-and-Respond (High Velocity)
Choose this when:
- You're running a SOC 2 Type II audit focused on detection capabilities.
- Your team ships multiple microservices with diverse dependencies.
- You have SIEM integration and 24/7 security monitoring.
- Your developers can evaluate package risk independently.
- You need to adopt new packages within hours, not days.
Implementation requirements:
Install dependency scanning in your CI/CD pipeline using tools that check for known vulnerabilities and anomalous package behavior. Configure runtime monitoring to detect unexpected network connections or file access patterns—the Telnyx attack would have triggered alerts on encryption operations and data exfiltration attempts.
Deploy package signature verification. Pin your dependencies to specific versions with hash verification in your requirements files. Monitor your package repository for unauthorized version updates to packages you use.
This approach satisfies SOC 2 Type II CC7.2 (monitoring system components) and CC7.3 (evaluating security events). It aligns with NIST Cybersecurity Framework v2.0 function DE.CM-4 (malicious code detection).
The operational cost: you're trading proactive control for reactive speed. Your security team needs the capability to investigate alerts within 30 minutes and make containment decisions quickly. If you can't staff that response model, this path creates risk without value.
Path C: Hybrid Gating (Balanced)
Choose this when:
- You need both velocity and control.
- You have distinct dev/staging/production environments.
- Your compliance scope allows detective controls in non-production.
- You can enforce promotion gates between environments.
Implementation requirements:
Allow unrestricted package installation in development environments. Require security review before promoting to staging. Use automated scanning and manual review before production deployment.
Configure your CI/CD pipeline to block production deployments if dependencies haven't passed security review. Maintain an approved package list for production but allow exceptions with documented risk acceptance.
This satisfies PCI DSS v4.0.1 Requirement 6.3.3 (code review before production) while preserving development flexibility. It maps to ISO 27001 control A.8.31 (separation of development and production environments).
The operational cost: you need mature CI/CD pipelines with environment-specific configurations. Your security team reviews packages on-demand rather than blocking all installations, but you still need the review capability.
Summary Matrix
| Factor | Allowlist-Only | Monitor-and-Respond | Hybrid Gating |
|---|---|---|---|
| Best for compliance | PCI DSS v4.0.1 Req 6.3.2 | SOC 2 Type II CC7.2 | ISO 27001 A.8.31 |
| Review burden | All packages, pre-install | Post-incident only | Production-bound only |
| Developer friction | High (approval wait) | Low (install freely) | Medium (gate at promotion) |
| Response time needed | N/A (preventive) | <30 minutes | <4 hours |
| Team size minimum | 2 FTE security | 3 FTE security + SOC | 2 FTE security |
| Tool investment | Private repository | SIEM + runtime detection | CI/CD + scanning |
The Telnyx attack used sophisticated encryption and targeted data exfiltration. Your chosen path should reflect your ability to detect that behavior (monitoring) or prevent the malicious package from ever reaching your systems (allowlisting).
If you're unsure which path fits your team, start with hybrid gating. It's the most forgiving option while you build detection capabilities and understand your actual dependency change rate. You can tighten to allowlist-only or loosen to monitoring based on real operational data.
The wrong choice isn't picking monitoring over allowlisting—it's picking a control model your team can't actually execute.
