Alex van Rossum is the security lead at MipYip.

Independent reviews of an application before launch, or when the owner wants a second opinion on what they were told about it. A review covers the code and the live configuration of the systems it runs on, and reads the terms of service, privacy policy and subprocessor list against what the system actually does.

• Authentication and authorization, including whether one user or tenant can reach another’s data
• Injection, server-side request forgery, unsafe deserialization and known-vulnerable dependencies
• Secrets in source and configuration, and how credentials are stored and rotated
• Salesforce field-level security, object permissions and sharing
• Findings rated on likelihood and impact, with a recommended fix for each

Containment first, then root cause, then the persistence an attacker left behind. I have run response on compromised production WordPress servers, including a compromise that sat silent for eight days before it surfaced, and the investigation that followed it to a second compromised server.

• Containment, removal of backdoors, rogue accounts, scheduled tasks and database-resident payloads, and credential rotation
• Malware artifacts preserved before deletion, and a written after-action timeline
• A server-level brute-force jail that does not depend on per-site plugins, and longer ban times on most servers in the fleet
• ASN blocks and rate limits at the CDN against scanner traffic that was saturating a server
• After-action reports and a reusable compromise-response playbook

For a Salesforce production org, every permission grant and revocation goes through one tool. It records who granted what to whom, why, and who authorized it, in an append-only ledger that is reconciled against the live org. A grant or revocation is blocked unless a reconciliation ran in the previous 14 days.

• Drift detection for access that exists in the org but not the ledger, and the reverse
• Changes to what a permission grants are tracked separately from who holds it; changes to an existing permission set go to a sandbox first and are checked with a permission query after deployment
• Anything a non-administrator will use is tested while logged in as a user who holds only the new grant
• Changes to the sharing model, integrations or connected apps get an independent architecture review before the change is closed out
• In cloud accounts: removal of dead IAM users and orphaned policies, and an MFA enforcement policy

Hardening for server fleets, Kubernetes and the edge in front of them, written down as standards so the next person can apply them the same way.

• Scripted fleet audits for unsupported operating systems, end-of-life PHP and brute-force protection state
• Fleet-wide removal of a plugin with a known unauthenticated file-deletion vulnerability, with verification afterward
• A Cloudflare standard covering strict TLS, minimum TLS version, staged HSTS, WAF rules for login and XML-RPC, rate limits and bot handling
• A standard Kubernetes workload pattern with default-deny ingress network policies and token-required instance metadata
• Public-access blocks on cloud storage buckets and retention policies on log groups

Finding credentials where they should not be, and putting new workloads on a pattern that keeps them out of source.

• A scanner that inventories credentials embedded in deployment manifests
• A standard pattern for new workloads: secrets from a managed parameter store, mounted at runtime instead of stored in the deployment
• Rules for AI agent use on repositories that hold embedded credentials: a training opt-out, a local model, or excluding the credential files from the agent

I use AI agents heavily, which makes their permissions a security question. Agents that touch client systems work under a declared write scope, propose changes by default rather than make them, and need explicit approval for each production write.

• Hooks that require confirmation before an agent makes a direct production permission assignment
• Reviewer agents that run as separate processes in an operating-system sandbox and cannot write to the code they review
• Quarantine for content pulled from a compromised system: it is handled as data and never as instructions, and it must pass a written sanitization procedure and human review before it reaches a new build
• An email classifier built to resist prompt injection: content inside nonce-tagged boundaries, no tools, a strict output schema, and a safe default on any malformed output

A read-only scan of what a website discloses to anyone on the internet. It runs at a polite rate, honors robots.txt, and never authenticates or attempts an exploit.

• Security headers, TLS certificate validity and HTTP-to-HTTPS behavior
• Exposed files such as environment files, version-control directories and configuration backups
• WordPress user enumeration, XML-RPC exposure, and known vulnerabilities in core, themes and plugins
• Blocklist status and signatures of injected or cloaked content
• A site with no findings is reported as having no indicators found, because an external scan cannot prove a site is clean

Some risks are not mine to accept. When the fix needs budget, a vendor change or a business decision, the risk is written into a register the owner can act on.

• Likelihood-by-impact rating, with mitigation, contingency and residual risk for each item
• Each risk has an owner named by role
• Risks that cannot be fixed in the current engagement are recorded and handed off in writing