Public-safe engineering patterns.
Ten patterns showing how I reason from risk signal to design decision, fix path, validation, and repeatable control — without exposing private work.
Public-safe patterns showing how I reason through security engineering work. They use generalized scenarios and mock data — not client stories, employer projects, or private environment details.
Most M365 tenants accumulate configuration drift over time. Admin roles expand, Conditional Access exclusions widen, app consent grows unchecked, and the gap between intended security posture and actual posture grows.
Risk travels through overpermissioned admin roles, authentication gaps in Conditional Access, broad OAuth app consent, external sharing settings, and missing audit log coverage.
Global Admin count above 3 · Standing privilege on accounts that should use PIM · CA policies with broad exclusions · Third-party apps with full mailbox or directory access · Audit log retention under 180 days · Legacy authentication not blocked
Reduce the blast radius of any single compromised account by enforcing just-in-time privilege, tightening CA policy scope, restricting third-party app consent, and enabling the highest-value Defender signals.
Map all Global and privileged role holders. Enable PIM for standing privilege accounts. Review CA exclusions and remove stale ones. Audit app consent and revoke over-permissioned apps. Enable audit logging at 180+ days. Block legacy authentication.
No standing Global Admin accounts outside break-glass. PIM approvals functional. CA policy report-only period shows no unexpected blocks. Legacy auth blocked per sign-in logs. App consent limited to admin-consented apps.
A tenant where any single compromised account cannot affect every user, where every admin action is logged, and where authentication requires more than a password.
Conditional Access policy changes are high-risk because a misconfigured policy can lock out users, block emergency access, or create unexpected authentication gaps. Most failed CA deployments share one cause: the change was not tested before enforcement.
Overly broad enforcement locks out valid users. Overly narrow exceptions defeat the purpose. Forgetting break-glass accounts creates lockout risk. Moving too fast from report-only to enforced without reviewing the data causes production incidents.
CA policy in report-only with no review date · Break-glass accounts not excluded from enforcement · No pilot group defined before enforcement · Policy change deployed directly to all users · No sign-in log review after enforcement
Use report-only mode to preview impact, pilot enforcement with a small low-risk group, review sign-in logs before widening scope, and always verify break-glass access works before enforcing any identity policy.
Create policy in report-only mode. Review sign-in log impact for 7 days. Assign enforcement to a pilot group. Monitor for unexpected blocks. Stage rollout to larger groups. Enforce broadly. Verify break-glass access independently.
Report-only data reviewed before enforcement. Pilot group enforcement shows no unexpected blocks. Break-glass accounts authenticate successfully outside policy scope. Rollout completed without production incident.
A CA change that completed rollout with zero lockouts, verified break-glass access, and a documented evidence trail from report-only through enforcement.
Access permissions accumulate faster than they are removed. Stale accounts, overpermissioned roles, inactive guest users, and forgotten app integrations are common discovery targets in any identity review.
Stale accounts with active credentials provide initial access for attackers. Guest users with persistent access create persistent lateral movement risk. App integrations with write access become a privileged path that bypasses user-level controls.
Accounts with no sign-in activity in 90+ days still enabled · Guest users with access to sensitive resources and no review date · Service accounts with interactive login capability · OAuth apps with write or directory access not reviewed in 12+ months · Role assignments without documented justification
Disable before deleting. Assign ownership before revoking. Review activity before deciding. Every account, guest, and app integration should have an owner, a business justification, and a review date.
Export all accounts with last sign-in. Flag accounts inactive 90+ days. Disable and notify owners. Review guest users by access level. Revoke app integrations with write access that are not actively used. Document what was removed and why.
No enabled accounts with 90+ days of inactivity. Guest access list reviewed and signed off by business owner. App consent limited to actively used integrations. Role assignments have documented owners.
An identity environment where every account, guest, and integration has an owner, a documented purpose, and a review date.
Most vulnerability management programs fail at the handoff from scanner output to remediation. The scanner finds hundreds of issues. The engineering team receives a spreadsheet. Nothing gets fixed because everything is marked Critical.
Unvalidated scanner output wastes engineering time on false positives and low-impact findings. Missing business context means the wrong things get prioritized. No ownership mapping means no one acts. No retest criteria means closure is never confirmed.
Vulnerability backlog growing faster than closure · CVSS scores used as the only prioritization signal · No distinction between internet-facing and internal findings · Findings without assigned owners · No documented false positive process · No retest evidence in closed tickets
Validate exploitability before reporting. Add business context before prioritizing. Assign an owner before handing off. Define retest criteria before marking closed. Reduce the list to what can actually be acted on.
Review scanner output against live environment context. Remove confirmed false positives with documentation. Assess each remaining finding for actual exploitability. Add asset criticality and business impact. Assign to owners. Write owner-ready tickets with fix steps and retest criteria.
False positive rate documented. Each finding has one owner. Owner-ready tickets include fix steps and acceptance criteria. Retest confirms fix. Closure rate tracked by priority tier.
A remediation program where every open finding has an owner, a fix path, a priority based on real exploitability, and a retest step that proves closure.
Most organizations do not have a clear picture of what is visible to an attacker before any credentials are used. DNS records, email authentication gaps, SSL configurations, and exposed services are rarely reviewed as a unified attack surface.
Email authentication gaps enable phishing at scale. Misconfigured DNS enables cache poisoning. Exposed services provide initial access. Certificates without CAA controls allow unauthorized issuance.
No DMARC enforcement · SPF missing or using soft fail · DNSSEC not enabled · CAA records not set · Shodan-indexed services on unexpected ports · Login pages without MFA prompts · SSL certificates expiring without automated renewal
Start from the outside. Enumerate what is visible without credentials. Validate what is genuinely reachable and exploitable. Prioritize by realistic attack scenarios, not theoretical risk.
DNS review for SPF, DMARC, DKIM, CAA, DNSSEC. SSL configuration check. Certificate transparency review for unexpected subdomains. Shodan review for indexed services. Login surface inventory. Prioritize findings by exploitability.
DMARC at p=reject. SPF with -all. CAA records set. DNSSEC enabled. No unexpected services exposed. Certificate transparency shows no unauthorized issuance.
An external attack surface where phishing is technically harder, DNS is tamper-evident, certificates are controlled, and exposed services are intentional.
AI tools are being adopted faster than security policy can follow. The result is unclear data flows, ungoverned model access, unreviewed vendor terms, and no process for deciding what AI use is acceptable.
Sensitive data enters AI tools without visibility. Vendor retention policies vary and are rarely reviewed. DLP controls often do not extend to browser-based AI tools. Output from AI tools influences decisions or actions without human review.
No formal AI tool approval process · Users entering customer data or source code into consumer AI tools · Vendor data retention not reviewed · No logging of AI tool usage · AI output acting on data without human sign-off · No acceptable use policy for AI tools
Start with data movement, not model behavior. Understand what enters each tool, where it goes, and what the vendor can do with it. Build approval tiers based on data sensitivity. Make acceptable use specific enough to enforce.
Inventory all AI tools in use, approved and shadow. Map data categories each tool can access. Review vendor retention and training data policies. Assess DLP coverage. Define approval tiers. Write acceptable use policy. Build review process for new tool requests.
All AI tools in use are in the approved inventory. Vendor data handling reviewed and documented. DLP coverage verified for high-sensitivity data paths. AI tool request process operational.
An AI tool environment where every tool in use is approved, data exposure is bounded, vendor terms are reviewed, and output handling includes human checkpoints for sensitive decisions.
SaaS access accumulates without a lifecycle process. New users get access. Roles expand. Offboarding is inconsistent. OAuth permissions grow unchecked. The result is a large, unaudited attack surface of accounts and integrations with more access than needed.
Offboarded users with active SaaS credentials become orphaned accounts. OAuth apps with broad write access become privileged paths for compromised accounts. Role creep leaves users with more access than their current job requires.
Offboarding checklist does not include SaaS revocation · OAuth apps with write or directory access not reviewed in 12+ months · No role review process for access that was correct at hire but has expanded · Guest and contractor access without expiration dates
Every SaaS user needs an owner, a role justified by current job function, an offboarding step, and a periodic access review. Every OAuth integration needs an owner, a documented purpose, and a revocation path.
Catalogue all SaaS apps and active users. Cross-reference against HR offboarding records. Review OAuth permissions. Build quarterly access review process. Add SaaS revocation to offboarding checklist. Document app ownership.
Offboarding checklist includes SaaS revocation. OAuth app inventory current. No accounts active for offboarded employees. Quarterly access review completed.
A SaaS environment where every active account matches a current employee, every OAuth integration has a documented owner, and access review is a repeatable process.
Code repositories are a high-value target: they contain source code, secrets, credentials, infrastructure configuration, and deployment pipelines. Most repository security problems are configuration issues, not attacks.
Unprotected branches allow direct commits to production. Missing CODEOWNERS means no required reviewer. Secret scanning disabled or misconfigured. GitHub Actions with excessive permissions. Dependency updates unreviewed.
No branch protection on default branch · Push to main without pull request · No required reviewers · Secret scanning disabled · Workflow files with write permissions to all resources · No dependency review on pull requests · Environment secrets accessible to all workflows
Enforce code review for every change to protected branches. Require secret scanning. Restrict workflow permissions to minimum required. Add CODEOWNERS for sensitive paths. Enable dependency review.
Enable branch protection with required reviewers. Add CODEOWNERS for security-sensitive paths. Enable secret scanning and push protection. Set default workflow permissions to read-only. Enable dependency review. Review environment secret access.
Branch protection active on default and release branches. Secret scanning enabled with push protection. Workflow permissions defaulting to read. All environments require explicit access approval.
A repository where every merge requires review, secrets cannot be committed accidentally, workflow permissions are minimal, and dependency changes are reviewed.
Recurring manual checks, noisy alerts, and repetitive triage tasks are candidates for lightweight automation. Good signal automation reduces cognitive load, improves consistency, and makes security checks repeatable without requiring a dedicated person to run them.
Manual checks get skipped when people are busy. Inconsistent processes produce inconsistent results. High-volume alerts without prioritization logic create fatigue and missed signals.
The same check being run manually more than once a week · A triage decision that follows a consistent rule most of the time · Alert volume that makes every individual alert feel low-value · Findings that never reach the right owner because routing is manual
Automate the repeatable part. Keep humans in the judgment loop. Build visibility into what the automation is doing. Make it easy to override or adjust.
Identify the recurring check or decision. Map the logic. Build the smallest automation that reliably handles the repeatable part. Add logging. Test edge cases. Document override process. Validate output against manual process for one cycle.
Automation runs reliably on schedule. Output matches expected results from manual baseline. Override process documented and tested. False positive rate within acceptable bounds.
A lightweight, documented automation that runs the repeatable part reliably, surfaces the right signals to the right people, and does not require manual intervention to stay accurate.
Most security findings that go unfixed do not fail because the risk was unclear. They fail because the finding did not give the owner enough to act. Missing fix steps, unclear ownership, and undefined success criteria are the most common causes.
Without a specific fix, owners guess. Without a specific owner, nobody acts. Without retest criteria, closure is never confirmed. Without business context, urgency is not felt.
Findings with only a description and a CVSS score · No assigned owner on open findings · Fix steps that describe a concept instead of a specific change · No definition of what done looks like · Remediation updates that say 'in progress' with no detail
Every finding handed to an owner needs: what is wrong, why it matters in this environment, how it was validated, what the specific change is, who owns it, and what a successful fix looks like.
Write a technical description of the issue. Add a plain-English explanation of the risk. Include validation evidence. Write specific remediation steps. Assign a single owner. Define retest criteria. Include an executive summary for escalation.
Owner confirmed understanding of the fix. Fix implemented as specified. Retest criteria met. Finding closed with evidence.
A finding that the assigned owner can act on without scheduling a meeting to clarify what security wants.
None of the patterns here represent a specific employer, client, or engagement. All examples use generalized scenarios, mock data, and sanitized methodology. No internal metrics, environment counts, or NDA-protected details are included.