Moving cybersecurity towards an engineering-centric future

Security spent two decades watching software engineering grow up around it and barely changed. Development teams learned to own their own quality, then their own infrastructure, and the disciplines that made those shifts possible (cross-functional ownership, repeatable frameworks, tooling that makes the safe path the easy one) only recently started reaching security at all. The question this LimaCharlie panel circles, hosted by co-founder Christopher Luft, is not whether security should become more like engineering. Everyone takes that as given. The harder question is what "engineering-centric" actually means once you stop talking about secure code and start talking about the operational work that happens after software ships. The three panelists answer it from three different vantage points, and the disagreement between them is the most useful thing in the session.

Two halves of the same problem, at very different stages

Larry Maccherone, who ran DevSecOps transformation across 600 development teams at Comcast and now works at Contrast Security, owns the front half of the lifecycle: building software securely. His read on the industry is historical. QA used to be a separate department you threw work over the wall to, and those dedicated orgs have nearly vanished as teams absorbed ownership of their own quality. The same thing happened with operations once a developer could provision a server with three clicks. Security is simply the next silo to fall, and even an organization ahead of the curve, which is how he describes Comcast, is only at the very beginning of that shift.

Maxime Lamothe-Brassard, LimaCharlie's founder, accepts all of that and then draws the line that animates the rest of the conversation. Maccherone's world is the leading edge. The trailing edge is everything that happens once systems live in production: incident response, investigation, detection. That work still runs on what Lamothe-Brassard calls arcane knowledge, an analyst reasoning from personal experience rather than a method anyone else can reproduce. Engineering-centric, in his framing, means treating operations the way the scientific method treats inquiry. Put a framework around it so an industry can learn and improve, instead of leaving it locked in one person's head. He is honest about why this half resists the developer-centric fix. You can take a Java developer who just untangled a logic bug in their own app and they will feel the pain and write better code next time. You cannot easily take that same person and ask them to hunt for credentials being dumped out of LSASS on a domain controller. That is day and night, and it is the part of the spectrum that has changed least.

The real obstacle is trust, and it has a formula

When Luft asks why security stayed stuck on black-box tools while engineering raced ahead, Lamothe-Brassard points to incentives. The vendor path of least resistance has always been fear, because the ROI on selling "the APTs will get you" beat the ROI on the hard, metrics-driven engineering case. Maccherone takes it somewhere more specific. The barrier between security and development is a lack of trust, and he offers an explicit ratio for it: trust grows with credibility, reliability, and empathy, and shrinks with apparent self-interest. Security people privately think developers ship hackable code; developers think security people do not understand that without features there are no customers and no data worth protecting. Neither side feels understood.

What makes this more than a slide is how he operationalized it. He built credibility by staffing his program exclusively with active developers and scrum masters, not certification holders. A resume with security acronyms and no recent code went to the bottom of the pile. His coaches kept writing code half their time, building self-service tools for the engineering teams, precisely so they would not drift out of touch. He shrank the self-interest term by emphasizing shared stakes. And he separated preventive work from incident response on principle, refusing to let his experts get pulled into the pants-on-fire firefight, because urgent work always crowds out important work.

The numbers he reports are the part an MSSP or MDR should sit with. By the time 150 of the 600 teams had gone through the program, those teams had roughly one-sixth as many production incidents and vulnerabilities as the teams that had not. That translated to about one-fourth the reactive headcount needed downstream, which he rolls up into a 24x return he used to justify pushing the remaining teams through. For a provider deciding whether to sell reactive labor or build repeatable prevention into the service, that ratio is the whole argument.

The on-ramp, the people, and the limits of buying your way out

The mechanism all three keep returning to is a shallow on-ramp. Transformation dies when it opens with a 300-page policy manual, because the team freezes and waits to be forced. Maccherone's framework, which he builds at transformation.dev, is less a list of controls than a method for changing behavior: hand a team one to three concrete things they can finish inside 90 days for the biggest risk reduction, then coach and tool-smith until doing it themselves is easy. His org-level version is sharper still. Get the three to five most respected engineers in the company, the ones everyone wants to be, in a room with security, and do not let them out until they have produced a weighted, ordered list of granular practices written in language engineers actually parse rather than NIST or PCI phrasing. Because those engineers built the list, they advocate for it. He calls it a little social engineering for the engineering team. Anderson echoes the same instinct from the consulting side, where governance and compliance objectives overwhelm manufacturers when dumped all at once: chew the elephant in small bites at a time, because trying to do everything at once is how the effort fails.

On people, the panel refuses the easy answer. Lamothe-Brassard argues the fix is not tripling the number of warm bodies but raising the floor of what entrants already know, the way calculus migrated from university into high school. Joe Anderson, a senior cybersecurity analyst at TechSolve with 25 years across managed providers serving manufacturing, healthcare, and finance, attacks the self-imposed wound: entry-level postings demanding a CISSP screen out exactly the coachable, soft-skilled people, some of his strongest hires were English and Spanish majors, who could have grown into the role. Maccherone reframes the shortage entirely. Most organizations already have enough headcount; they have the wrong skill mix, and transformation may even let them reduce it.

That sets up the MSSP question Lamothe-Brassard puts directly to Anderson, whose small and mid-size manufacturing clients simply cannot staff this work in-house. Anderson advocates for partnering out, but he warns it carries real trade-offs and will not solve every problem. Maccherone's caveat matters most for how a provider positions itself: the work that outsources cleanly is the conveniently siloed, after-the-fact work like penetration testing and threat modeling. Keeping development in-house while outsourcing security and still claiming to be engineering-centric does not hold together. The opening for a provider is the repeatable operational layer clients cannot build themselves, delivered as engineering rather than as a black box with someone pushing buttons. Maccherone's name for the tooling that makes this work is a cognitive prosthetic: an engineer should not need to recall every detail of SQL injection in advance if the platform catches it in their code and hands them a short explanation after the fact. The same logic, embedded inside the application rather than bolted on outside it, is what let runtime protection block Log4Shell-class attacks without waiting on a firewall signature. The platform should do the remembering so a smaller team can spend its scarce judgment on the work that cannot be reduced to a rule.