Follow

Training, tools, even competent engineers are no match for perverse incentives. Infosec is still quick to bash engineers based on flaws in products & assume they don't "get" offense. I too once thought the fix belonged with engineers, maybe training, but let me tell you something: top ~10-20% of devs I've worked with already know how to attack their product, know enough to be training their peers, & given ~months to re-train would easily make better offsec hackers than most that spent ~years..

· · Web · 1 · 0 · 0

.. there's a staggering amount of hubris among hackers who've never built stuff. Including myself as an engineer: I didn't "get" how dominant the shape of an org, its people systems, feedback loops (or lack thereof), commercial settings etc were until I spent a few years exposed to management/inter-BU/customer things on larger teams.

In a fight between a smug infosec rockstar vs 87 sprints under a tunnel-visioned SCRUMlord, yrs of 0% slack time & career-driven-development, I know who I'd bet on

.. I know this is obvious/boring, but there's others who should know better on birdsite & it wasn't always obvious to me: the front of my career was a mix of small/large orgs but always in small teams, often as the lone coder, personally accountable but always empowered

Maybe I'm just unlucky, but scrumgile seems to create pathological 1-way relationships w/product owners & devs who cope via learned helplessness, desensitized to issues they could fix if only owners would put them on the backlog

Honestly the scrum guide reads like some kind of cult

It assumes the Product Owner knows best, and everyone Shall Respect the Product Owner

Clearly then the single most impactful thing you can do for an organization's security program isn't tools or training, it's to ensure product owners understand their security goals and how to achieve them when faced with the various dysfunctions unique to their environment

@csirac2 I only "did" scrum in one place and maybe we didn't do it right, but our planning discussions were more of a level playing field where the Product Owner argued what the Product (ie sales and customers) wanted and the devs argued what was viable or necessary from technical side and we came to some kind of course consensus for each Sprint.

Which was a part I appreciated: because even good developers can lose sight of the user/customer/product perspective, and opposite is tech debt city

@csirac2 mostly I'm just sad I missed the chance to say: I only "did" Scrum in one place, and I didn't inhale

@csirac2 I think in this regard Scrum as a process doesn't fix organisational pathologies: if your organisation ignores tech debt and engineer priorities, Scrum will just reinforce this. If your development culture is technology centric and often builds the wrong thing from a user/customer angle, scrum probably won't fix that either (although it might be a power play from management in that direction, I acknowledge)

@projectgus FWIW it's certainly possible to have tech debt city *and* disgusting waste on nothing stakeholders care about, I'd never have believed the amount of code that can be written which had no business being written until I'd seen it myself..

I shouldn't have made my rant about scrum.

Perhaps it's just my career path atm, but I find there's often surprise around poor security outcomes, but when we add up lack of explicit seceng goals/investments it should really be opposite of surprising

@csirac2 yeah, those are fair points. I think your criticisms are fair ones (and I don't think from the security perspective as much as you do.)

Probably the main thing I'd argue is that, in my experience, dysfunctions are usually reflective of organizational values. Processes can offer ways to do those things more effectively, but they won't significantly change the values by themselves (despite claims made by enthusiastic Agile consultants and the like)

@csirac2 I think I'm getting a lot of this from Bryan Cantrills writing about technology values, which I've been thinking about/around a lot lately. Highly recommend if you haven't already read.

@projectgus enthusiastic consultants: yes, definitely a thing! We can't SCRUMgile all our problems away.. I might be misinterpreting but there seems to be a pervasive premise that developers are fungible, perhaps in some markets for some projects that works but it's far from true in more challenging contexts - at the very least, effectively applying individuals IMHO means considering their unique capabilities (& weaknesses) in the team. I've read some of bcantrill's stuff but not enough :)

Sign in to participate in the conversation
Mastodon

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!