From what Iāve read, thus-far, prohibiting autotools would be a good 1st-step.
Then auditing all the damn ocean-of-vulnerability-in-a-single-crufty-swamp dependencies, & getting committed about clarity & accountability in packages, would probably be required.
I read an article, a couple years ago, about web-frameworksā¦
The guy doing the writing said he found they were often malware, or corrupt, or trojans, or utter-bullshitā¦
Haskellās got a kind of mantram: donāt bring in a whole framework, just compose what you need, yourself, together.
Its a granularity-difference.
Requiring a framework, which itself requires other frameworks, as that guy was pointing-out ( he wasnāt interested in Haskell ), is a liability nightmare.
But the culture of just having an infinite bring-in of frameworks & libraries, so one can write a little, easy code, is a culture that is biting the worldās security in the ass.
It cannot be, that people just include everything from everywhere, & somehow have secure/trustworthy systems.
To have a secure, trustworthy system, one needs to know that one has disincluded corruption/malicious-code.
That requires limiting whatās included, that includes auditing, that includes accountability, that includes having understandable, sufficiently-clear stuff that one is including.
Consistently, at all levels, relentlessly.
Itās a chain: you cannot have a weak-link without compromising the whole chain.
You cannot compromise ANY subsystem in a distro, & have a trustworthy distro.
There are 2 contradictory paradigms: the āmagic bullet paradigmā, which doesnāt care how much rot, compromise, anything, so long as they include the āmagic bulletā which takes-out the competitorā¦
ā¦ vs the āno weak-points, whatsoever, paradigmā, which doesnāt rely on magic, it relies on defense-in-depth, and carefulness, and everybody working coherently, etc, in order to disallow corruption/malicious-actors any leverage/grasp on us.
They are cultures, not just ideas.
Some people cannot tolerate a āno weak-pointsā culture, they āNEEDā to compromise things ( I donāt care about the bugs, get more features in!!" ), and they must be put out into the other organizations/operations, because they CANNOT tolerate careful-paradigm.
It truly is a culture, or āreligionā, and thereās no faking it.
Look to OpenBSD, & see what it takes to be like themā¦
As the real gurus of Agile point-out,
most of the nuveau methods/processes were ideological,
but agile had engineering-requirements, too ( test-1st develoopment, e.g. )
Which makes it much superior to all the ideology-but-no-engineering-hardening methods.
As they also pointed-out, you NEED disciplined individuals & teams to make it work.
IF you donāt have effective & driven-by-quality/integrity-of-work teams, agile isnāt the right method for you.
Iād go further:
Iād say that both waterfall & agile ( Wysockiās book on project-management identifies that Traditional is the poorest match for reality, Agileās best, & Extreme is research whereas Emertxe is where youāve got a solution, but donāt know what itās for, yet ( like Post-it notes glue, before sticky-notes were invented ) )
both waterfall & agile are mis-apprehensions of whatās required.
Until you understand the required architecture, you canāt make the right architecture-choices, right?
So, why not make a prototype agilely, until one has a proper domain-model, an executable toy-prototype which demonstrates all the key functions, & then when youāve got the working, executable model, then you understand the architecture required, and only then do you switch from agile-prototyping to building-out the real, hardened thingā¦
Just seems sane, to me, but Iām just some idiot with a bit of thinking, not a working ā¦ anything, really.