Hey everyone — I'm pretty new to the whole Dev/Infra tooling space, but I'm trying to get up to speed for our marketing ops team. We're a team of 5, and we use a mix of marketing automation (HubSpot), a custom-built analytics dashboard, and we're increasingly pushing stuff to AWS (S3 for assets, some Lambda functions for data processing).
I've been evaluating Claw as a potential addition to our stack for security and code quality. We don't have a dedicated DevOps person, so I'm looking for tools that are manageable for someone with more of a marketing ops background.
Anyway, I just finished setting up a custom check in Claw to scan our repositories for hardcoded AWS access keys. I know this is a huge no-no, but we've had a couple close calls where temporary keys got committed by mistake during campaign microsite deployments. Our stack is primarily JavaScript (Node for the Lambdas) and Python for some data scripts.
We considered a self-hosted option for the scanning tool initially, but given our small team size, we prioritized a managed service to reduce overhead.
Has anyone else built similar checks? I'm curious about:
- What other types of secrets (beyond AWS keys) are most critical to flag in a marketing/ops context? Database connection strings, maybe API keys for services like SendGrid or Salesforce?
- How do you handle false positives? I'm tweaking the regex to avoid catching example placeholders in our documentation.
- Do you run these checks pre-commit, or more as a periodic audit?
I'd love to hear how other teams, especially smaller ops-focused ones, are handling this. It feels like a bridge between dev security and our operational workflows.
That's a great first custom check - hardcoded AWS keys are definitely one of the most critical things to catch early. For your mix of JavaScript and Python, I'd immediately recommend also adding patterns for:
- API keys from services you're likely using, like HubSpot itself, SendGrid, or any social media platform APIs. These often have similar formats to AWS keys.
- Database connection strings, especially if any of your Python scripts connect to a data store.
- Internal bearer tokens or JWT secrets if your analytics dashboard has its own auth.
A caveat on managed services: they're fantastic for reducing overhead, but make sure you understand where your code is being scanned. Some teams get uncomfortable with their code leaving their VPC, even for a security scan. Did you run into any internal policy hurdles there?
~jason