Security is never convenient. You have to lock your door. You have to put your seatbelt on. But if wearing the seatbelt required folding a pile of laundry every time, nobody would do it. The key to DevSecOps is making security as convenient as possible while still protecting what matters. Kyle Fossum, Staff DevOps Engineer at The Predictive Index, is responsible for developer productivity, Azure infrastructure architecture, and cloud security posture. In this episode, he shares practical approaches to balancing speed with security, why self-serve tooling changes everything, and how GitOps provides security reviews that manual processes cannot.
You can read the complete transcript of the episode here >
How do you find the right balance between DevOps speed and security?
Security is always going to add some overhead. The question is how much overhead is acceptable for the business. Kyle frames this as a risk management decision:
- It depends on organizational appetite: A hedge fund with billions to protect will restrict local admin access and audit every tool installation. A startup where velocity is everything might give everyone production access because the business demands speed.
- Align security with business objectives: Someone with both comprehensive security understanding and tight business alignment should make these decisions. Security controls disconnected from business context create friction without proportional value.
- Make security convenient: The seatbelt analogy is key. If the security control is a simple slide-and-click, people will comply. If it requires a lengthy approval process, they will find workarounds.
The practical example: developers needed to update secrets in Azure Key Vault but only DevOps had access. This meant passing secrets over Slack, handling them outside their system of record, and waiting for DevOps availability. The fix was self-serve tooling that let developers submit secrets through a pipeline where they get encrypted and deployed securely without DevOps involvement. More convenient for everyone and more secure.
What are the biggest DevSecOps challenges in cloud-native environments?
Kyle emphasizes that the shared responsibility model varies significantly between service types:
- IaaS (Virtual Machines): You do not handle data center security or physical cables, but you are entirely responsible for OS configuration. Every misconfiguration is on you.
- PaaS (Managed Platforms): You do not worry about the OS, only the workload running on the platform. Less surface area to misconfigure.
- SaaS (Third-party Software): You are not even responsible for the platform, but you still control IAM and access for the product.
The challenge: understanding exactly where responsibility lies for each service type. The recommendation to overcome this:
- Standardization via SSO: If ten SaaS applications each have separate user accounts, off-boarding requires remembering to disable all ten. With single sign-on tied to one identity provider, one deactivation propagates everywhere.
- Configuration management: With hundreds of app services and thousands of configurations, finding where a leaked secret is used requires comprehensive observability across the entire estate.
- Infrastructure as code: Bake correct security defaults into templates once, and every deployment inherits them automatically. No clicking through portal menus hoping you got it right.
How does GitOps improve security over traditional PR reviews?
Traditional PR reviews catch code issues, but GitOps adds downstream validation:
- Eliminates human targeting errors: Without GitOps, after PR approval you pull main and execute locally. How do you ensure you are targeting the right Azure subscription? (Kyle admits knowing this from personal experience.)
- Enables downstream testing: Merge to main triggers continuous deployment to a development environment. Developers immediately test the infrastructure and catch issues before production.
- Parallelizes security checks: Dynamic application scanning, integration testing, and security scans can run simultaneously during deployment, adding minimal time to the pipeline.
- Provides audit trail: Every infrastructure change is tied to a commit, a reviewer, and a timestamp. This is audit evidence that portal clicking cannot provide.
The insight about debugging: in computer science, when you hear hoofbeats, think zebras not horses. Across layers of abstraction, the obvious stuff has already been ironed out. If something is broken, it is likely something unusual that warrants close investigation.
What DevSecOps best practices should organizations follow?
Kyle highlights several foundational practices:
- Do not embed secrets in code: Use secret stores like Azure Key Vault or AWS Secrets Manager. Credential commits to source code happen constantly; build tooling that assumes this will happen and detects it quickly. Secret scanning tools can automate this detection.
- Infrastructure as code is imperative: Bake security defaults into templates. You configure correctly once and every deployment inherits it. This also enables peer review of infrastructure changes.
- Observability across the estate: When a secret leaks, you need to know everywhere it is used across potentially thousands of configurations to rotate it effectively.
- Blameless postmortems: Credential commits happen because humans make mistakes. Pointing fingers creates a culture where people hide mistakes rather than reporting them quickly. Focus on quick detection and robust secret rotation processes instead.
- Automation for force multiplication: With 100 servers, you cannot hire 100 people to click menus. Automation is essential, and if misconfigured, at least the fix propagates just as quickly.
How should organizations implement MFA effectively?
Kyle has strong opinions on authentication best practices:
- SMS-based MFA is insufficient: Social engineering and SIM jacking allow attackers to receive your SMS tokens. YouTube demonstrations show how easily this is done.
- Hardware tokens are best: YubiKeys and similar devices cannot be remotely compromised. Nobody is going to steal your physical hardware token over the internet.
- Authenticator apps are a strong middle ground: Preferably integrated with a password manager like 1Password.
- Apply MFA broadly: Every employee has something an attacker wants, regardless of level. Customer service has user account access. Finance has financial data. Security is not just for engineers.
- Use adaptive MFA to reduce friction: Same IP address as always? Delay the prompt for 30 days. Login from an unexpected country? Full verification required. This balances security with usability.
On passwords specifically: NIST has revised its guidance. Length beats complexity. A 20-character passphrase in plain English (the famous “Correct Horse Battery Staple”) provides security until the heat death of the universe but is easy to remember. Arbitrary password rotation requirements with no indicators of compromise just annoy users into writing passwords on sticky notes.
What advice do startups need for starting their DevSecOps journey?
Kyle’s practical guidance for resource-constrained teams:
- Assess current state first: You need to know where you are before deciding where to go. Maybe you are committing secrets to source code. Start there.
- Set clear goals aligned with business: Early in his career, Kyle spent time implementing security features nobody asked for. In startup environments, minimum viable security aligned with business objectives matters more.
- Foster collaboration over compliance: Security is a journey, not a destination. The threat landscape changes constantly, and continuous improvement must be baked into the culture.
- Environment-specific priorities: A fintech startup handling managed brokerage cannot treat security as an afterthought. A consultancy with limited PII has different priorities.
- Start with the highest-impact basics: Secret stores, cloud misconfiguration scanning, and remediation tooling provide the most value for the least effort.
The overarching principle: security needs to be at least convenient enough that people will not try to circumvent it. If password requirements are so complex that people write them on sticky notes, you have failed at security, not succeeded.
