The Human Element of Security
Despite rapid advancements in development velocity and artificial intelligence, security remains fundamentally a human problem. Most security incidents still stem from human error or involve human interaction. Even those that don’t result directly from human mistakes can often be traced back to an engineering culture that failed to prioritise security—and that’s not their fault.
For most companies, security is a function of sales enablement—proving to customers that security practices meet expectations is essential for doing business. As a result, CISOs and their security teams often inherit a controls framework that combines the strictest requirements from customers, regulatory bodies, and industry compliance standards.
The complexity of these frameworks varies based on factors such as:
- Location (e.g. GDPR vs. CRA)
- Market (e.g. Singapore’s highly prescriptive fintech data protection directives)
- Internal & compliance standards (e.g. SAMM/ASVS or SOC2)
Interpreting the security controls superset is further complicated by company culture, which shifts as organisations grow. For example, a CISO at a company focused on reducing churn might prioritise coaching and cultural improvements over blocking releases for third-party vulnerabilities. However, this stance can change quickly when customers or regulators demand stricter controls—or when a surge in cyberattacks unlocks additional security funding.
Ultimately, security teams reach an unavoidable conclusion: there is no one-size-fits-all security solution. Long-term security requires continuous adaptation and under-the-hood customisation to match and maintain pace with evolving needs.
Enter the Security Monolith
The ever-changing nature of security doesn’t align well with the traditional venture capital approach. Most VCs push for minimal solutions that serve the largest audience, which makes sense from a business investment standpoint. However, this mindset has led to a proliferation of “don’t-think-about-it” monoliths—startups wrapping open-source tools, LLM APIs, or basic CRUD applications in rigid business logic layers.
Meanwhile, security teams face constantly shifting threats and need solutions they can adapt to whatever fire they’re putting out this month.
The challenge in building adaptable security products is, cost. Every decision must be carefully weighed to avoid unnecessary complexity which ends up slowing development, a counter-intuitive choice in small companies.
The result? Inflexible, uncustomisable solutions that force security teams to rely on a patchwork of dirty hacks, workarounds, and internal tools just to get the job done.
This is not good enough.
Security solutions should enable DIY. Users should be able to:
- Define custom detection rules
- Modify how detection data is processed
- Integrate post-processing solutions as they see fit
All of this should be achievable without hacking vendor dashboards or reverse-engineering APIs.
The DIY Debacle
At Smithy, customisation limitations surfaced as a top industry concern in more than 100 discussions. Our first two design partners already had internal systems that required custom data transformation, handling, and integrations.
Fortunately, we saw how AppSec leaders like Semgrep tackled this challenge—open-sourcing their rules engine and exposing arguments in their binary, giving users full control over the Abstract Syntax Tree (AST).
The Smithy Approach to DIY
We believe in an elegant approach to DIY security.
1. Transparency
- One of our competitive advantages is how easily Smithy integrates with new systems.
- Being transparent ensures users understand how integrations work.
- As an Open Core platform, most of our code is publicly available on GitHub, so users can see exactly what happens under the hood.
2. Extensibility
- Users are encouraged to develop and contribute their own components.
- We provide an SDK, libraries, and utilities to simplify the process.
By prioritising transparency and extensibility, Smithy ensures that teams don’t just understand how their security tools work—they own their security workflows.
This means:
- Full control over data collection, processing, and presentation
- A user-friendly experience with contextual defaults, guardrails, and automation
Security teams shouldn’t have to fight against their tools. They should be empowered to shape them to their needs.
For Example: ZAP Integration
Smithy includes a DAST integration using ZAP by default.
With the standard ZAP integration, users can:
- Point to a URL for a generic ZAP scan
- Upload a ZAP Automation Framework file to orchestrate scanning
This is powerful and flexible. However, we quickly learned:
- The ZAP Automation Framework is an excellent but slow-moving feature
- Many teams, including ours, prefer orchestrating ZAP through its REST API
So, after launching the ZAP integration, we refined it to allow custom orchestration scripts.
A small modification in the YAML integration now enables users to:
- Upload and manage their own orchestration script libraries
- Directly control how scans are executed based on their workflows
Our solution architects even help teams refine their scripts, ensuring the feature evolves to meet real-world needs.
Similar to Semgrep: Customisation at the Core
At Smithy, we’re big fans of Semgrep—both its operational model and the tool itself.
We recognised early on that supporting custom rules was essential, so we helped customers write custom rules from day one.
Initially, we let users select their preferred Semgrep rulesets. However, this quickly evolved into a need for fully custom rules—so we built support for defining individual rules within user-defined configurations.
This mindset—empowering DIY security teams—guides every integration and feature in Smithy.
Closing Thoughts
Security tooling must be customisable to the point where teams can:
- Modify detection logic
- Control how data is processed and visualised
When new threats emerge or business needs shift, CISOs shouldn’t have to wait on vendors. Instead, security teams should be able to adjust their tools in under a sprint.
This is where Smithy makes the difference.
Smithy gives our customers the tools and visibility they need to solve DIY security challenges—without workarounds, without vendor lock-in, and without compromise. By enabling transparent, adaptable, and extensible security solutions, we empower teams to stay ahead of evolving threats on their terms.