The Air Force’s chief software officer quit because its technology was so bad
Cybersecurity is not looking great these days.
This story originally featured on Task & Purpose.
If you’ve ever struggled with a government computer still running on Windows 2000, know that you’re not alone. In fact, the military’s cybersecurity infrastructure and software development enterprise is in such a bad state that the Air Force’s first-ever Chief Software Officer will soon resign because it isn’t worth fighting the entire bureaucracy of the Department of Defense just to get some basic information technology issues fixed.
“We are running in circles trying to fix transport/connectivity, cloud, endpoints, and various basic IT capabilities that are seen as trivial for any organization outside of the U.S. Government,” wrote Nicolas Chaillan in a LinkedIn post announcing his resignation on Thursday. “At this point, I am just tired of continuously chasing support and money to do my job. My office still has no billet and no funding, this year and the next.”
For those who might be thinking “what do I care about software? Let the nerds figure that one out,” hear this: Many experts believe that future conflicts will be won and lost based on our ability to develop new software.
“Success in tomorrow’s conflicts will largely depend on how warfighters are able to harness and adapt everything from mission systems on aircraft to sensor packages, networks, and decision aides,” retired Air Force Lt. Gen. David Deptula and Heather Penney who are respectively the dean and senior resident fellow for The Mitchell Institute for Aerospace Studies, in a July policy paper on network and software development.
“To prevail in a dynamic and contested battlespace, warfighters must be able to reprogram and reconfigure their weapon systems, sensors and networks,” they wrote. “Yet the Air Force continues to develop, update, and manage software and architectures in a highly centralized and stove-piped fashion.”
Apparently the old Air Force recruiting slogan, “It’s not science fiction, it’s what we do every day,” does not apply to the branch’s bureaucracy, which Deptula and Penney argued is stuck in a bygone era.
“The bureaucracy of Department of Defense funding categories also prevents software tools from being fielded and employed,” they wrote, which means warfighters are always a step behind their changing battlespace. “This is a recipe for failure given tomorrow’s challenges. To put it bluntly, software and networks shouldn’t be governed by industrial age processes.”
It was that kind of bureaucracy that also made Chaillan’s three years on the job a Sysphean task just to get simple projects done, at least according to his LinkedIn post.
“I’m tired of hearing the right words without action, and I called on leadership to ‘walk the walk,’” Chaillan wrote. “That includes funding, staffing and prioritizing IT basic issues for the Department. A lack of response and alignment is certainly a contributor to my accelerated exit.”
There are several specific experiences that impressed on Chaillan how little military leadership actually cares about cybersecurity and software development. One of those is DevSecOps, which is short for development, security, and operations. DevSecOps is a process by which software developers keep security central to every step of software development, rather than tacking it on at the end of the development cycle, according to IBM.
Chaillan wrote that he was very proud of his team creating the DoD Enterprise DevSecOps Initiative, which began spreading the holy word of DevSecOps to the backwards cyber-heathens dwelling in the Pentagon. But even that process is often like pulling teeth, Chaillan wrote.
“[Our leaders] have repeatedly refused to mandate DevSecOps, not even for new starts in custom software development!” he said. “There is absolutely no valid reason not to use and mandate DevSecOps in 2021 for custom software. It is borderline criminal not to do so. It is effectively guaranteeing a tremendous waste of taxpayer money and creates massive cybersecurity threats but also prevents us from delivering capabilities at the pace of relevance, putting lives at risk[.]”
The same problem applies to implementing Zero Trust systems. Those are software security steps like when Gmail or Facebook texts you a verification code just to make sure you’re not a hacker. You’d think national security secrets would have a better layer of security than my company’s Mailchimp account, but apparently not, according to Chaillan.
“[W]e hear the leadership talk about Zero Trust implementations without our teams receiving a dime of funding to make it happen,” he wrote. Nowadays, DoD is willing to put more money where its mouth is in terms of Zero Trust, but it’s not using any of the early work Chaillan and his team did on the subject last year, he said.
“Why waste more taxpayer money playing catch up?” the software officer wrote. “The ‘not invented here’ syndrome is powerful in DoD and our leadership is not willing to stop it.”
The ‘not invented here’ problem refers to a widespread habit of different military agencies, or even different tribes within an agency, doing their own version of the same project without sharing information or best practices. This is even a problem between different fighter jet programs in the Air Force, wrote Deptula and Penney in their analysis.
“Although the F-22 and F-35 are the only two 5th generation fighters in the Air Force inventory, they cannot share information with each other machine-to-machine,” because they use incompatible datalinks that were developed 10 years apart, they wrote. “Today, the F-22 and F-35 fleet still cannot exchange information without the aid of an externally hosted gateway, one which is still in the experimentation and demonstration phase.”
Read more about the Air Force’s IT meltdown over at Task & Purpose.