DevSecOps is often misunderstood
Why DevSecOps isn't a tool problem, but a decision problem. And why I'm starting OnlyOle exactly there.
DevSecOps is often misunderstood. It's not about adding more tools. It's about making the right decisions. And that's exactly where most teams lose time. Not because they can't do it, but because they're optimising in the wrong direction.
I see it again and again in conversations with teams who've hardened their pipeline, scanned their images, and brought in a SAST tool. On paper that looks like serious security work. In practice they're still standing in front of the same questions as two years ago: who's allowed to deploy what? How do secrets get into the build? Who's responsible when the scanner alerts? The tools are there. The decisions aren't.
Tools are cheap. Decisions are expensive.
You can buy yourself good tooling in a few days. Rolling it out takes a few weeks. But a clean decision on who's allowed to do what in which environment, who really works which alert, and which risks an organisation knowingly accepts — that takes posture and calm. It can't be replaced by another SaaS licence.
I see teams who add 300 findings to their vulnerability backlog every month and close none of them. That's not a scanner problem. That's a prioritisation problem. A team that doesn't dare to say: "these three findings we'll work this week, the rest waits." A team that's being driven by its tooling landscape instead of steering it.
It's similar with pipelines. Every organisation has YAML today. Not every organisation knows who has access to the secrets in that YAML. Who patches the runner. What happens if the ex-admin from two years ago left their personal tokens in there. These aren't tool questions. They're governance and decision questions.
Why I started OnlyOle for exactly this
With OnlyOle I deliberately go a different way than with my agency. No projects. No slides. No long analyses. I work 1:1 with at most five customers per month on exactly those decisions a team can't make on their own — because they're politically, technically, or organisationally uncomfortable.
A session isn't a pitch. I don't come with a product catalogue. I come with questions. Where is it bleeding right now? Which decision have you been pushing for three months? What would you do if you'd had an hour's sleep and nobody could contradict you? Often that's enough to loosen the knot. The rest is craft, and teams can usually do that themselves.
I deliberately limit it to five customers a month because the time I invest per case is genuinely meant. I keep working in projects at Moselwal during the day and see there what works and what doesn't. OnlyOle is the place where I pass that knowledge on in short, focused conversations — without anyone having to buy a three-month consulting project to get an hour of real clarity.
What I want from this format
I'm no fan of consulting models that live by the consultant staying longer than they should. My goal is the opposite: after a session, the customer should be able to take the next three steps themselves. If they never speak to me again afterwards, I've done my job.
That sounds unusual, I know. But in 23 years I've seen enough customers who were helped more by a clear answer than by an 80-page PowerPoint. For me, DevSecOps isn't a collection of tools at the end — it's a leadership style. Whoever has that style needs few tools. Whoever doesn't can buy every tool in the world and will still get lost in their own complexity.
That's why I'm starting OnlyOle right now. Not as a scaling play, but as a clear counter-offer to an industry that prefers selling to listening. Five customers a month, no slides, no excuses. If you're noticing right now that your team is optimising in the wrong direction, that's the entry point.
Questions I often hear about this
A few things readers regularly ask me about this topic.
Do you have specific tools you'd recommend anyway?+
I currently use different tools depending on context, and I'm deliberately not dogmatic. More important than the specific choice is that a team sticks with one and that someone is clearly accountable. I'm happy to name names in conversation, but only once it's clear what exact problem the tool is meant to solve.
When is OnlyOle not the right fit?+
If someone's looking for a service provider who stays longer and does the implementation, I'm the wrong person. I deliberately stay short and offer impulses. Anyone who needs someone working in their pipeline for three months will find the right format at my agency — but not at OnlyOle.
Does this also work for small teams without a dedicated security role?+
Especially then. Small teams often have the more honest problem: they know full well that nobody holds the role, and they hide that behind tools. I help to make accountability explicit — even when in the end it sits with one person who does it on top of everything else. That's uncomfortable, but more honest than yet another licence.
What does an OnlyOle session actually look like?+
I work like this: first listen for what's really hurting right now, then isolate one concrete decision that's been getting pushed for weeks. In the hour we have, we try to make that one decision. No roadmap, no slides — just clarity about the next step.
Don't we still need good DevSecOps tooling?+
Of course. I'm not against tools. I'm against starting with tools before it's clear who makes which decision. A good SAST tool without clear accountability just produces more backlog. That's why I look at the decision structure first, and only then at the tooling.
If you want to talk this through in more depth
I advise individual IT leads under OnlyOle — 1:1, no agency overhead. If this keeps nagging at you and you want to sort it out in your own context, give me a call or drop me a short message.