Pentagon declares war on 'outdated' software buying, opens fire on open source The US Department of Defense (DoD) is overhauling its "outdated" software procurement systems, and insists it's putting security at the forefront of decision-making processes. Katie Arrington, CIO at the DoD, established the department's Software Fast Track (SWFT) initiative via a Monday memo [PDF], which promised to reform …
I see nothing wrong with that: Things must get worse before they get better.
Let the beatings commence until morale improves!
icon: mine's got the s'mores with it. Watching the world burn is turning into a great spectator sport, you're never left waiting for the next round.
Just the opposite: the stupid, insipid Orange Man currently in power was put there by selfish, ignorant Trump supporters.
Like children, they'll only learn when they suffer from their own actions; you can try to tell them anything and they'll just ignore you for their own "reality".
So, very much like the very worst children, they need to learn responsibility for their own actions. Meaning: they need to SUFFER like they planned everyone *else* would. It must get worse before they learn so things can then try to get better. We've been fighting with these ignoramuses for centuries, since the Civil War, and they need to finally be punished for their recidivist stupidity.
This post has been deleted by its author
This post has been deleted by its author
Loads but that is "Agile"
Does lots of stuff really fast
Deliver something that mostly works
Do more stuff really fast, fix some of the mess from the first release, break some more.
Deliver more new funky features that don't work but PMs are happy,
Rinse and repeat.
Security?????
Nah, who needs to test security, there was a pen test 9 months ago. The fact that this shite did not exist then passes the developers by,
Warning Opinion follows---- The problem with Agile is that it is a race to the bottom in most cases. The concept of "Minimum Viable Product" should have been a hint that there was trouble on the horizon. The key word is "Viable" and to those who look at a project from an enterprise perspective Viable has a different meaning than the business unit who is paying for the project to be done. To the business unit Viable only means "gets what I need done done"
And an MVP need not be anything that a sane person would use for an entire day: it provides the basic functionality needed for the Customer Representative to determine if that functionality is accurately provided - and is actually the functionality that the Customer can use (which isn't the same as the initial requirements description - part of a working Agile process, if you can find one, is that the Customer also adjusts their ReqSpecs in light of seeing that that what they thought would work to solve their problem isn't actually correct: hopefully close, not not all there). The MVP can gather all the data from all the subsystems accurately (but doesn't have the module to let it log into all of them, so you type in those credentials by hand) and performs all the calculations accurately (but at 1/219th the speed it will do once you've signed off on its accuracy and we spend the time with the trickier API to speed it up) generating a report that is concise and easy to understand (but is only available in English, it'l go to the translators once we are certain that we have all the messages required and have written the full User Manual, so we can be sure they all get translated together and are consistent) and you have to send it to the printer queue yourself.
But the MVP is viable enough that the Customer Representative can finally get a running executable which can be taken it onto a Customer site and parallel run with realistic data, its reports compared against expectations and generally used absolutely "for real".
Compare an MVP for a combi clothes washer and drier: it works, gets your clothes clean and dry, but that is all: it lacks the niceties, like a solid metal case to stop you putting your hand on the spinning drum and the controls are labeled in two kinds of sharpie and a sellotaped note.
> and the controls are labeled in two kinds of sharpie and a sellotaped note.
Absolutely. If you let developers get to a full fat UI without stopping for Product Increment reviews, you’ll end up with the impenetrable user experience that is the app for my washing machine.
"The use of personal phones and commercial apps introduces unnecessary risk. Signal is considered unclassified by the government for a reason. It's clear that US government systems are having a hard time keeping up with the required pace of business."
No, senior leaders are just having a hard time obeying their own orders.
The problem with Signal is, due to its cross platform operation, the protocol will negotiate with the highest level of encryption available in common between each participant. Hence, if one client can only receive in the clear, all traffic then can go in the clear.
Meanwhile, we use by default and operational necessity higher bit key escrow systems, keeping as much as possible within one's enclave for classified communications beyond CUI on each security domain's own double encrypted network.
And I've watched dumbasses compromise each domain serially, via unauthorized removable devices crossing security domains in a decidedly unauthorized manner, resulting in mitigation efforts that for the first remediation, cost $1 billion and the second remediation because they still couldn't follow directives and orders, remains classified in cost to this day. After all, if one's superiors ignore orders, why should oneself follow them? And no, the network I was responsible for remained uninfected, because I did follow the orders given. Which meant, while the scofflaws got to put in tons of overtime to clean up their own mess, I was happily in my quarters enjoying a fine tipple.
And the scofflaws called me a cowboy, for following lawful orders to maintain just basic security. No wonder the company lost its contract and since, was absorbed by a competitor.
>> "The problem with Signal is, due to its cross platform operation, the protocol will negotiate with the highest level of encryption available in common between each participant. Hence, if one client can only receive in the clear, all traffic then can go in the clear." <<
Errr, no.
Citation needed!
Yes, and when you need to evaluate the code you want to run the best way to do so is ask a chatbot:
"The DoD currently has multiple requests for information (RFI) running until late May that seek industry input for various matters of the initiative, such as how best to use AI to authorize secure software and what effective SCRM requirements would look like."
No no no!
The issue isn’t with Open Source per sa but with companies using it as a pre-made assembly.
Any company wishing to do business with US government agencies simply needs to establish a code reading and QA department for all Open Source. Obviously, specialists will arise, but given American’s love of mega corporations, expect the majors to step in and do the work for a monthly subscription based on their pre-existing licensing rules.
<sarcasm>Microsoft is an obvious candidate for the QA, it has decades of experience with Windows et al.</sarcasm>
Aside: apologies, I’m sure to fully comply with ElReg commenting guidelines and good practise, I should colour code the above.
Huh? Use instead software that comes with no source code that can be examined for security flaws or back doors?
What could go wrong?
Try banning the use of personal devices and use locked-down government -issued devices instead.
Don't hire or appoint idiots...well, any more idiots.
Sounds to me like exactly the sort of nonsense Arthur C. Clarke warned us about three quarters of a century ago. Superiority
Standups and short-arm inspections weekly, Fridays, at beer o'clock. It's just a different kind of "pull request".
"So the Army and Airforce are going to be forced to use a language invented by an Admiral?"
COBOL like ADA probably wouldn't suffer from buffer overflows or use after free defects.
Hardly imagine this new lot of nongs are likely to require new software to be coded in Rust or Go or any other memory safe language. Mandating Ada never worked although AdaCores SPARK Ada derivative wouldn't be the worst choice.
As always getting a usable specification out of those newly sporting the mandated Warrior Ethos might prove definitively impossible. "Listen here! What the fuck do you actually want? I will rephrase that. What the fuck do you think you want?"
I imagine there are smiles galore in Moscow and Peking not forgetting Pyongyang where most of the code will likely be written.
How stupid can stupid get before it ceasing being just stupid but something qualitatively and not just quantitatively different and possibly completely novel? Hyperstultality? I am afraid we may well be doomed soon to find out.
Yeah, but they have to "appear" to be "doing something" because the Commander in Chief as ordered them to "do something"
Most militaries have centuries of experience at appearing to stuff they don't want to do, stalling, prevaricating or whatever, especially when asked to something stupid :-)
"wide open, no oversight, no bid, sole-source contracts."
Without detail specifics, all of those things might be the optimum way to go. There's no point in putting out RFQ's for biros and reams of paper. Buy it locally as needed. Obviously, if the local shops suddenly double the price for boxes of #2 pencils without wholesale prices having done the same, that could be a reason to remove them from the approved vendor list. Sweating the small stuff costs more money than just getting on with it. If it makes more sense to buy in bulk and have central warehouses distribute common supplies, it can be done that way with policies that allow buying local to cover shortages.
The same things as above can apply to software. There are loads of applications on my computers that do a specific task and I bought the first one I came across that looked likely to do the job. My FTP program is what it is and I've stuck with it as I don't need advanced functionality and I've learned its ins and outs over the years. On the other hand, I spent a lot more time deciding on CAD programs to standardize on. In those cases, it was more important to make evaluations.
I'm sure a framework can be decided surrounding updating and product changes that will need scrutiny if there are security implications. Vendors may need to bid, supply raw code for validation and have patches and upgrades approved in advance. For there to be bidding, there needs to be more than one company offering an application. I seem to get by pretty well without having to hire a firm to write custom software for me. That's also the patch of ocean where dragons lie and treasure ships slide beneath the surface with not a trace.
Having worked for DoD on classified systems I can pretty much tell you that you don't run down to the nearest office supply place and buy 15 or 20 new computers. Military outfits buy in lots of a couple thousand at a time. Also NSA and DISA get picky about what's put on them.
"I've seen those thousands of computers ordered by just ONE military branch come down my production line"
And I'm sure there was an RFQ with invitations to bid for those. My point that went whizzing by is that there's a massive difference between that sort of purchase and one for a block of Post-it notes. Computers are also somewhat standard for office applications and it's scary to award contracts to the lowest bidder, companies that don't normally sell/configure computers and the ones specifying One-Hung-Lo branded components.
"no "outdated software". "
What would that even mean. I have software that's old (bought more than a year ago) and perfectly fit for purpose. What often yanks my chain is a new OS coming out that breaks an old program that will never be updated. I then have to find a replacement and buy yet another application that I'm going to do the same things with.
First, as of now, the US government should stop using software, firmware or any OS that was not written entirely by US government employees with security clearance from before they began coding, who have passed the pro-Trump purity test. Until new software is written, messages can be sent by landline or pigeon. But only if the pigeons have passed the pro-Trump purity test (animal version).
Secondly, the USG is in danger of running short of secure TLAs. A committee should be established as a priority to develop new ones, that can only be used by government employees with security clearance who have passed the pro-Trump purity test. For security reasons, the actual words that the TLAs stand for will remain a state secret.
Thirdly, an immediate audit should take place to ensure that USG employees are not using BIC ballpoint pens. BIC is a French company and France has not yet been annexed by the United States. This is potentially Huawei all over again.
Any USG employees with Bics are bringing their own. The standard USG writing implement is provided by Skilcraft and represents the state of the art in anti-pilfering technology. Supply rooms aren't emptied overnight by amoral GS-15s—mostly because they're never stocked in the first place, but also because Skilcraft pens suck so hard that nobody in their right mind would consider taking one home with them.
Good luck to DoD if they try to operate without French and German smart cards, though.
France has not yet been annexed by the United States.
Apart from Louisiana. ;)
There goes resurrecting Multics as it is owned by a Groupe Bull subsidiary, a French company and open sourced ages ago.
Whether the US could build a GE-645 nowadays is a moot question let alone the later Honeywell machines.
This post has been deleted by its author
This post has been deleted by its author
Parts of that "report" display a fundamental lack of understanding of how software works in the 21st Century. "The fact that the department currently lacks visibility into the origins and security of software code hampers software security assurance" is an outdated attitude to OSS that has no place in 2025, let alone in a top-security department.
Just another example of deploying "the best people" (i.e. "have passed the Trump purity test") in the most important positions.
You won't be able to determine the security of software based on location of the developer. Your country, as well as every other, contains evil people who will intentionally subvert security procedures and incompetent people who will break things by accident. This is why you have to analyze what you're running to some extent, which is indeed difficult. If they decide that doing that with open source software is too hard, they can write everything they run themselves, which will be expensive and means a lot of things they'd get by default with open source they will have to pay for, but maybe it will provide better results. Alternatively, they can use the fact that lots of people should be analyzing open source software when they're running it to distribute the costs of doing this across many organizations running the same stuff, which does happen some of the time already. Alternatively, they can do what most institutions have done so far, they can just not bother to analyze what they're running and hope for the best. Hoping to do it based on nationality guarantees that you'll get bad results while some clueless person thinks they've figured it out.
How is understanding the provenance of the software going into your system an outdated attitude for those concerned with high-assurance systems?
That a lot of OSS is a bit of a free for all certainly makes establishing provenance pretty difficult (if not impossible), and that might make it undesirable to include such software in your system (unless steps are taken to establish that it has not been compromised). However, unless the need for such checks is stated (and given value) it will not happen.
Provenance should not be a sole factor in determining that a piece of software meets the assurance levels needed for the system, but it adds to the evidence that is used to build the assurance case.
The story of the 1980's construction of the US embassy in Moscow illustrates how provenance and control over the origins is important. The initial US belief had been that it was OK to let the Soviets build the embassy as they could sweep it clean when they took possession. This proved to be so impractical (due to a good deal of "mischief") that it ended up with only a specially checked/protected room inside the building being considered secure. (That story is contrasted with the construction of the Russian embassy in Washington - which had a stringent security programme throughout its construction).
[article]
This post has been deleted by its author
And Windows NT 3.1 with no network access… I'm too lazy to search but I do recall several warships being shutdown due their use of Windows™…
Happy days. Still at least Public Idiot Number One (Pete Pisshead) got that TV studio so that we can look forward to Pentagon and Friends!
This post has been deleted by its author
I am only going back to the later 70s, but cannot remember any US written code that wasn't bug ridden.
Prior to that I was told that IBM wouldn't let their programmers write anything longer than a printer page as they couldn't be trusted if they had to turn the page over.
They didn't like me taking the Micheal out of them at the interview either.
If it stood over them and gave them a golden shower! Having been head of a company that made OSS products, anytime our sales 'roids got around US DoD it was a complete shitshow trying to deflect all the untruths and misconceptions their so-called experts had. Not that a single one of them had ever contributed to or worked with OSS beggared belief and if one asked them about compiling BIND or Sendmail they stared at you like a deer in the headlights.
No matter how many PIN tests, external vendor penetration tests we wasted hundreds of thousands on, their goons wouldn't accept.
...
Department
Of
Dunces
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
