For those of you with no government experience I suspect you have absolutely no idea why this is so challenging.
The military is allergic to internal software. First of all you have to understand IT in the military is a different world far beyond your imagination because everyday they are under attack by the best nation-state cyber intrusion people on the planet. Your start up will never experience this and the mega corp, like Facebook will only just barely experience anything like this because it’s just not that important. The only commercial organizations that even come remotely close to what the military experiences daily are large financial organizations. Also, don’t forget the US military is the largest single employer on the planet, like 4.5 Walmarts.
So the military monitors everything at multiple levels. That also means locking things down to approved software lists at different levels. The people writing the security policies and/or performing the monitoring likely aren’t experienced software directors. They look at things like NPM and Maven and just see unlimited attack vectors from people who have no idea about security, and they aren’t wrong.
Then in the civilian and contractor space where do you put the code. If it’s paid for by the government then it’s owned by the government otherwise the contractor company wants to own it completely separated from the government so they can charge the government for it. Then consider if it’s a subcontractor not aligned to the financial goals of the prime contractor. Even when the government wants to do the right thing it’s complicated. As a software guy under a non managing co-prime I really don’t give a shit and say just give the government everything and it’s weird to see people try to throw up layers, especially since the government side is always less restricted because they almost always achieve vastly superior security accreditation on their infrastructure.
The depiction of the military's IT as nearly impregnable overlooks the widespread issues with outdated infrastructure and cumbersome policies that significantly impair its effectiveness.
While I'll acknowledge that certain areas within the US military might experience the level of threat and security sophistication described, the broader landscape is fraught with legacy systems that struggle to integrate modern solutions or best practices. These outdated systems/workflows/bureaucracy often result in inefficiencies and vulnerabilities rather than providing superior security.
You never hear about the US military getting broken into, not because it doesn't happen, but because it is classified when it does. Avoiding public embarrassment is the No.1 use of classification, resulting in this type of belief in their competence. I'd put Facebook ahead of the US military any day of the week, and it ain't close (who incidentally are a payment processor).
> The depiction of the military's IT as nearly impregnable...
Where was this depiction made by the OP? I only see descriptions of IT infrastructure that's under attacks of a nature and scale that not even software megacorps will ever see.
> and the mega corp, like Facebook will only just barely experience anything like this because it’s just not that important.
I worked at Microsoft, and speaking to their security team my impression was that MSFT is under persistent attack from nation states on a non stop basis, up to and including working to get government assets hired to work at Microsoft to leak secrets out.
Given the importance of AWS, I have no doubt Amazon is under similar threat.
For Microsoft to be in such a position makes sense, as they provide services for both US military and government (which also includes agencies), as well as for some infrastructure services. This is a pretty unique situation, compared to most other big tech companies.
Hell, there is a whole “Azure for US Government” product out there just for that, and that’s in addition to the usual AD/OneDrive/SharePoint/Windows/etc. suspects.
I would imagine Microsoft is a bit different because of the OS. If you can hack Windows you have access to nearly every institution in the world. Linux and iOS don't have that reach. No need to hack AWS, you hacked the computer that is logging into AWS.
The majority of cloud infrastructure is run on Linux.
You're saying there's no need to hack Linux when it's easier to hack Windows, and therefore Microsoft has better security fundamentals as the providers of a less secure but more prevalent OS? I don't follow the argument.
AFAICT this has very little to do with the military. Quoting from the actual bill:
(A) IN GENERAL.—This Act shall not apply to classified source code or source code developed primarily for use in a national security system (as defined in section 11103 of title 40, United States Code).
(B) NATIONAL SECURITY.—An exemption from the requirements under section 3 shall apply to classified source code or source code developed—
(i) primarily for use in a national security system (as defined in section 11103 of title 40, United States Code); or
(ii) by an agency, or part of an agency, that is an element of the intelligence community (as defined in section 3(4) of the National Security Act of 1947 (50 U.S.C. 3003(4)).
I quit contracting when over the course of a year I spoke to other sec teams in my branch, around my customers branch, my local contractor network and several vendors that told me another service branch had completed my exact project years ago and “why dont you just talk to them” was met with stares from my gov customer. Then you understand the racket that is gov contracting and why things take years longer than they should.
> US military is the largest single employer on the planet
Maybe not on the entire planet? I know it doesn't matter and it's not really anything but I guess that's not USDoD. But then again who believes Wikipedia anyway https://en.wikipedia.org/wiki/List_of_largest_employers. Besides even if it's true it's barely by a whisker and we shouldn't put further wars (i.e foreign freedom distribution enterprise) past the great nation of USA so that will change on a whim anytime. Cheers.
Also if this link is to be believed then 4 Walmarts (or even 4.5) will be really a lot.
> Your start up will never experience this and the mega corp, like Facebook will only just barely experience anything like this because it’s just not that important
I guess someone who’s never worked there could say this. Facebook is a treasure trove of data for details on domestic and foreign politicians.
Indian MoD 200,000 civilian employees, US DoD over 700,000 civilian employees - that's the part where the difference you'd expect shows up, not in the raw number of soldiers.
It shouldn’t be that shocking, the United States is the only country able to project military power globally. India can’t even provide basic sanitation for all of its citizens.
Poor countries can have enormous armies. The PLA during the late 1970s had like 5 million people in the ground forces alone. They have since cut that number by over 2/3 as they modernized.
>They look at things like NPM and Maven and just see unlimited attack vectors from people who have no idea about security, and they aren’t wrong.
Then what do they do? Aren't there tools to check for security vulnerabilities in the market like Sonar Qube? Wouldn't (or couldn't) the millitary run a beefed up version of that and developers can't check in code without ensuring 100% compliance to security vulnerabilities
They use approved software lists containing a list of software that is already approved, by vendor version number, for use within your organization. There are teams that analyze popular commercial software for approved usage, often including source code inspection. Bank of America does the same thing.
Tools like Sonar Qube are pretty shallow. Anecdotally, a robust development process will produce software that always reads clean on those scanners even if those scanners are not part of your development process. They detect defective development processes more than they detect defective code or designs.
Parts of the US DoD do have more rigorous testing that is considerably broader in scope than commercial linters and such, and evaluates for threats that commercial systems don't consider. Many of these tests reliably break open source software. It is unclear how thorough or exhaustive these audits or tests are -- it can be quite opaque. For good or bad, having been through several serious security audits by multiple organizations, my software always came back clean so it is difficult to calibrate their sensitivity from the outside.
Haha, very true.
It is insane how demanding and toxic some “developers” can be towards opensource creators and maintainers, as if they own them.
But on the other hand, open source or giving things out for free for people to try out and use is also a great way to find interesting friends who just want to build cool stuff together, and make new friends along the way :D
That part is prolly the only reason why I like opensource so much, it attracts certain kinds of interesting people depending on the project you’re working on.
Look at JVM exploits from the last years. They're usually chains of quite clever hops, for example from a serialisation or deserialisation vulnerability. Sonar is not going to help you with that and when something like it pops up it might already have been used 'in the wild' for some time, and then you have the problem of rolling out patches into the field.
Lots of audit and compliance tooling exists. What happens is they turn on a new datacenter, get 150k vulnerabilities, and then try to address them one by one. There's a lot of dead weight and incompetence in government IT.
I don't provide dedicated security services to start ups, so maybe I am outside my lane. However, it is my baseless assertion that nation-states are not dedicating entire teams and months of social-engineering research to backdoor a startup for non-monetary motives. I also suspect startups do not own the entirety of their own distribution infrastructure in production from the wheels, through the ISP, to the local keyboard.
The US Army at least uses Azure and AWS govcloud and not their own infrastructure. I don't think this takes away from your points though, the infrastructure is very locked down and meticulously managed and approved.
Resources even for nation states are finite. At minimum attention is a finite resource that limits ongoing operations. Active high value targets make sense: defense, infrastructure, finance and even to some extent media.
With that in mind, do you really think they’re interested in a startup that optimizes Google ads? Or how about postgres as a service with no clients of interest?
It’s not that I feel a sense of security but the low success rate script based attacks aren’t what I’m talking about here (or for that matter things like perpetual port scanning of the internet. Every entity seems to do this looking for holes), we are talking about active operations by skilled attackers. There is only so much of that to go around.
> ...I really don’t give a shit and say just give the government everything and it’s weird to see people try to throw up layers...
Yeah, this always struck me as so strange. I worked at a contractor where our customer really did own all of the deliverables, but I had peers who worked at contractors where that wasn't the case. To them, I was all like, "Guys. Our tax money is paying for this. Why are you rooting for pulling money out of everyone's pocket to massively enrich a few fat cats and sales guys in your company?".
Like, if you're of a "We're not going to give everything to the government" persuasion, then the reasonable way to handle that is to give the government the deliverables to do anything they want with, just so long as you're free to sell the unclassified components of it (and things derived from them) in the private sector to interested parties without interference.
I've seen it where development happens under one Customer, then a few years later they get some bad management and flounder, then a new Customer team (or teams) has pretty much the same mission. It's nice to be able to carry what you've already done with you vs starting over.
The Defense Sector is very much like the private sector in that it has hundreds of companies/teams doing pretty much the same thing.
> Under the law, agency chief information officers are required to develop policies within 180 days of enactment that implement the act. Those policies need to ensure that custom-developed code aligns with best practices, establish a process for making the metadata for custom code publicly available, and outline a standardized reporting process.
> Per the new law, metadata includes information about whether custom code was developed under a contract or shared in a repository, the contract number, and a hyperlink to the repository where the code was shared.
Sadly it doesn't sound like the law requires agencies to make the code publicly open source, it just requires inter-agency sharing (bill full text [1]). They only need to share "metadata" publicly.
> Sadly it doesn't sound like the law requires agencies to make the code publicly open source, it just requires inter-agency sharing
This is a good first step. The next would be sharing with states, municipalities and universities. Public sharing disperses a lot of IT responsibility that presently doesn’t exist.
And they will eventually learn that it's easier to share with the public at large than with a neighboring department.
At least that's my experience in a commercial setting: it's easier to publish something without restriction than to share it with a specific hardware or software partner only. The latter creates all kinds of questions around neutrality, applicability of NDAs, licensing, and so on.
What would be more interesting is to require all private companies who are doing US government contracts, especially the ones who are handling classified projects to do the same as these US agencies!!!
Gov-acquired software can be architected to separate open-source components from classified components. This enables reuse of commercial (open or closed) software with the economics and rapid iteration of larger markets. For open-source components, this enables public collaboration on COTS, with non-public collaboration on classified GO(v)TS components.
> The BRL-CAD source code repository is the oldest known public version-controlled codebase in the world that's still under active development, dating back to 1983-12-16 00:10:31 UTC.
It's practical for software vendors on platforms [1] with virtualization, which have been gradually increasing over the past decade, including Windows, ChromeOS and Android.
It doesn't help with doing any splitting (e.g. 20 years ago) but in current era where software is architected as micro-services and packaged for containers and VMs, software is more likely to be "born as reusable component".
I've signed many contracts with this clause. I've always interpreted it as "if you post what you did on HN and everyone responds saying you clearly shouldn't have done that", then it isn't best practice.
I mean, it’s not like we’ve ever seen this with the agile movement /s.
I’ve gone through “agile transitions” in government contracting, at a high level it starts out with a high concept idea of reducing lead times and increasing productivity. Then directives get handed down through layers of management, the decision is made to adopt Scrum or SAFe™, that gets handed down to middle management, who tailor the process in ways that specifically benefit themselves, and you end up with waterfall done poorly and with extra steps™.
What will happen is that there will be very loose definitions of source code and flexible definitions timing when code is released. If an agency does not want to share, they’ll find a way to evade, and still check off the box.
Sure, but won't there also be some agencies who voluntarily implement sharing in the spirit of the law? And won't that be positive for them and their dept's reputation?
Most DOE contracts (the ones the government has with the university or consortium running the lab) usually say something to the effect of “unless you can prove this source code is marketable/SBIR worthy, you can keep it private or open source it (but not under the GPL). There’s exceptions, but the reasoning was also there to say that _other_ contractors should retain the ability to modify source code and similarly not release it (presumably defense was my guess).
So the bar has been high to
keep it private for $$$ reasons, but you could always keep it private for any other reason.
DOE Code is the program that ostensibly tracks the open source software, usually just through github organizations. OSTI is the division that tracks all IP and research.
> IN GENERAL.—This Act shall not apply to classified source code or source code developed primarily for use in a national security system (as defined in section 11103 of title 40, United States Code).
The exemptions are extremely broad in section 4 of the act. I don't expect anything interesting to come of this reporting. Or for any money to be saved.
And I imagine there will likely be a sudden increase in the number of classified software projects and national security systems in the next 180 days. This may very well be another case of a law trying to make things better, but ultimately having the opposite effect.
Some things, like ZFSOnLinux are already shared publicly. The repository is now the OpenZFS repository and it has made many people's lives better. I know it has made my life easier. The open source development model benefited LLNL, which got a much better code base than they would have developed on their own. :)
There are other things already shared publicly like NASA IKOS:
That one gets far less attention from third parties than it should. If it could be developed into a general purpose sound static analyzer that handles multithreading, it would help to improve many other projects.
Even worse, it requires establishing new policies and staffing enforcement. They'll need to throw bodies at this effort, and so people building sytems will have even more pesky forms and policies and permissions to deal with. This will add cost and have very little, if any, positive impact.
This is typically the “smart but cynical” position I hear from some bureaucratic actors and those who aspire to become like them.
It’s the sophisticated version of “Don’t attempt any change” brigade’s position.
My observations from a lifetime in very large, cumbersome orgs is that improvement only comes from change and in highly dysfunctional, low-performance and low-ambition environments almost any reasonable change, supported by a really tiny number of engaged participants with a clue, leads to outsized positive step changes.
Even better, doing this as a sustained, tide-coming-in approach over several years can create more engaged people with a clue and slow transition to high-ambition, moderate-to-good performance cultures.
It’s worth the effort if you’re not doing it alone, and know that all the attempts pay off as part of a cumulative push. It changes lives both in the service delivery org, as well as those they’re supposed to support.
Sounds like you came through frustrated cynicism yourself to a kind of enlightened optimism and want to call it realist. I really appreciate this point of view and I'd like to get there myself, but here's the rub:
> tide-coming-in approach over several years
This phrase does a bunch of work, and seems to almost agree with the cynical perspective that individual small positive changes (or the more common failed attempt at the same) are futile. But if the difference between optimism and cynicism was only a matter of being patient and persistent, then we should be able to observe things getting better over time in a relatively consistent way.
Is that happening? Honest question, what large organizations can we point to that are better or more effective than they were 5, 10, 50 years ago? (And: for any situations where improvement happened, was it really a tiny number of engaged participants doing bottom-up change, or was it top-down change by some kind of executive decree?)
Youth without perspective will have a hard time answering maybe, but if the youth and wise old heads are both trending cynical at the same time then maybe the cynical position is actually true, and patience/perspective are simply not as relevant as the optimist would hope. My own experience is probably somewhere between youth/wisdom, and I tend to avoid large orgs as much as possible! But as an outsider, it looks like large orgs are all dysfunctional by default and only get more dysfunctional over time, with or without external pressures forcing that situation. Maybe there's a bureaucratic version of the laws of thermodynamics at work here.. the phenomenon of entropy isn't really cynical or optimistic or pessimistic after all, it's just the way things are.
Some people jump early. I’ve stayed long enough - or returned later on request after doing a startup - to see whole orgs and product lines in telcos (!!), banks (!!!) and even government agencies (yeah, wasn’t really expecting that tbh) getting structurally better over time due to concerted effort of a relatively small group of folks.
I’ve been part of turnarounds where senior execs have said that the three hundred people here will lose their job if nothing changes. I still talk to some of those teams that transformed themselves and others, and made it.
This was starting sometime in 2010, as gov.uk was gearing up IIRR, plus most people you talked to at the time in local government would just stare and not have a clue about open source. We have honestly come a very long way (I reckon we do a “generation” each decade - making me a third time around )
I've worked at military contractor jobs for years, and there are many people there who believe this - if the taxpayer is paying and the software isn't classified, then it should be open source.
Ghidra is a great example of this, and having this software be free has been of great benefit to the security community.
We create open-source software and attempt to get government agencies to adopt/use it. It's crazy how alergic these agencies are to open-source. Some will even create their own, with legacy style implementations (csv uploads, broken parsers), complete with bugs/flaws that are predicatble rather than use someone elses code.
When responding to RFPs, the open-source stuff has an a higher level of scrutinty than the closed systems. Like, if it's open then you have to show it's good but if it's closed the vendor just says "yep, we are perfect" and the agency could move on. It feels like the agency, and the employees don't want any responsibility. But I've never seen anyone lose their government job from some incompetence.
I heard this a lot before I started my career but IME this rarely pans out and you’re just stuck with broken software without documentation and source code.
>>>It's crazy how allergic these agencies are to open-source.
It’s about job protectionism on the greater scale and being the subject matter expert who leverages his code base for promotions on the individual scale. generally agencies do not view each other as working for the same team. It can be very competitive when lobbying for resources from congress for your agency.
I work in gov and speaking from first hand knowledge. The culture is toxic. It’s broken and I can’t wait to see what changes Elon and trumps team propose.
> This version is being posted to GitHub as an experiment in collaborative tools for public engagement of government policy documents. Suggestions for changes or additions to this document by military or civilian personnel, contractors, and private citizens may be submitted as pull requests..
Dan Risacher, from the DoD CIO's office, and open source security expert David A. Wheeler break down the history and ramifications of the recent DoD memo, which makes clear the Department of Defense's stance that open source is a viable, commercial form of software.
[Linux Foundation] OpenSSF recognizes the need for security education.. said David A. Wheeler, director, open source supply chain security at OpenSSF..Since its inception, more than 25,000 individuals have enrolled in this course material.
Good intentions but I don’t expect much to come except contractor 1’s would-be competitors closing the gap or using this to throw stones based on existing contract code quality. It is easier to write code than it is to read code!!
That’s cool. These are my expectations. Company 1 wins contract and builds something, key team members are experienced with making and navigating the “process”. Company 2 copy/pastes. They have not performed any work yet but they entered a bid X years later and bring up the years of “mediocre” dev Company 1 has done. There is only existing company 1 work and only hope of company 2. Contracting Officer chooses company 2 because promises sound good!
Reality, company 2 wins on cost and doesn’t understand the context of what was built or the environment it was built in. They don’t understand the costs as they didn’t pay them. Company 2 quickly proposes “full rewrite!” Lower cost labor they brought in can’t perform and quality degrades till we have (insert Gov software program here).
Ideally, a body such as NIST would become the stewards of federal libraries that contractors are then compelled to use and improve. If the end goal is about cost efficiency more than any other ideal or objective, then that type of centralisation and reuse should be promoted and enforced.
I'm not familiar with US government procurement, but the way public tenders for software work in the EU, this isn't that likely to happen. You need some serious references to even qualify for most tenders, especially the kinds that this would be a problem for.
Without serious corruption, you're not getting it. And with serious corruption, having seen the code won't make a difference.
Organizations often make a few missteps before figuring out what works. Some amount of failure is to be expected when doing anything on the scale of a nation. At least if everything's open, each attempt has the opportunity to learn from the last and can be evaluated on it's merits in comparison. It's also likely that other organizations will find some of the software useful.
This is great. I’ve spent some time working with gov teams where this is recommended practice [0]. In many cases though codifying as a requirement is still needed for that recommendation to be followed. This is particularly true for those who have not been part of OSS community before, which is common in public service.
As others have highlighted, public funds should lead to public good and open source is a great way to increase that benefit.
Awesome. I remember the pain of not even being able to read code within one and the same organisation, stuff like this I imagine will make work easier for anyone who builds top-down mental models.
In my country agencies use code as trade like "i will give you the code to generate holograms to by pass video KYC and you will give me men power to spread fake news".
Because there is no sharing, agencies spend a lot of money developing multiple versions of the same need, not all with great success. This bill should take you further in terms of quality and advantage.
No real risks, but this gives them a convenient excuse not to. I've had companies and government agencies refuse FOIA requests for technical documentation on privacy grounds because "it applies to a system that processes personal information", with some adding that "knowing the inner-workings of the system would lead to a likely compromise of the system".
Yes, government contractors will gladly admit between the lines that their code is garbage and they largely rely on security through obscurity. And the information comissioner has agreed with them a few times!
This article references "custom code." What about custom applications?
Are all government contractors required to provide the source code for all developed applications? Or does this bill only apply to contracts where the deliverables actually include source code?
by arguing the need to be sharing code (despite it not being the logical thing to do), you end up with (sub)contractors who will have more work to do to comply, and to make an otherwise simple system more complex by virtue of having to shove two separate systems together in one, so that they could be shared between agencies!
Sharing source code isn't enough. The right people need to be aware of its existence at the right time. For instance, there needs be part of their governance that due diligence be performed prior to executing a contract.
unless this is just an easy money grab for billions in contractors, with senators who own the businesses, to work as hard as possible at non-compliance
4(a)(1)(B) NATIONAL SECURITY.—An exemption from the requirements under section 3 shall apply to classified source code or source code developed—[...](ii) by an agency, or part of an agency, that is an element of the intelligence community (as defined in section 3(4) of the National Security Act of 1947 (50 U.S.C. 3003(4)).
I would like to see this go further. Have publicly funded universities develop "enterprise" government software such as DMV or other agencies, completely FOSS, and each year have a public hearing where the CEOs of the private contractors that currently provide this software can explain why, exactly, the FOSS version isn't good enough to replace theirs.
Generally speaking, anything and everything paid for with taxpayer dollars should be made public. Public Monies Public Goods should be the absolute basis.
That's already the rule, but the DoD is the only agency who takes it seriously (examples are BRLCAD and FalconView).
This doesn't stop unscrupulous contractors from copyrighting code and charging license fees (see: most DoE code, with exceptions like NWCHEM). I've often wondered why this hasn't resulted in any lawsuits; I suspect the reason is that nobody really cares.
> The report notes that the 2018 NDAA mandated DoD establish a pilot program on open source and a report on the program’s implementation. It also says that OMB’s M-16-21 memorandum requires all agencies to release at least 20 percent of custom-developed code as open-source, with a metric for calculating program performance.
It's 17 USC 105. Most agencies work around it by hiring contractors, which then leaves the copyright in the hands of the contractor. It's a loophole I'd like to see closed.
It depends on the contract. In the DOE system it's usually national lab employees working under direct funding; in that case the operating contractor retains copyright. In the DOD world it's more common for development to be actual USG employees, in which case there is no copyright and the software is public domain.
None of this applies to state or local government: 17 USC 105 applies only to federal matters.
Attribution tends to be important to DOE people since they're usually academics working in the purview of Office of Science, and citations are how they get promoted.
I don't think anyone worries about AI training on their codebases, since LLM providers are not held accountable to any copyright enforcement anyway.
You misunderstood my point about govt software contractors needing to worry about AIs being trained on their codebases: for their job security, automating and replacing them. Specifically, if the govt tries to do the same things we see in commercial SW devpt.
(Not copyright claims against commercial LLM companies).
If that were implemented at lower levels of government, it could increase costs for some while reducing it for others. If you're the State of Kansas and want to have software written for management of toll roads and toll payment accounts, you can spend a bunch of money developing it yourself, and then other states can freeload off your work. Or you can contract it out. If that contractor can then sell that same solution to other states, they can offer a lower rate to Kansas. But if they have to make their code available to all, they'll have to charge Kansas the full cost of development. If you're Nebraska and want to do the same thing as Kansas a few years later, you get a benefit from the spending Kansas has already done. Nebraska wins, Kansas loses.
It's more common for state governments to join forces to define standards for data, performance, features, and interoperability, and then require contractors to comply in the contract language.
I'm not aware of many contracts for bespoke software in the state government space; it's far more frequent that someone identifies a need and then develops a solution to bring to market.
The United States is a primarily open society. Keeping something as easily transportable as source code from another nation-state is nearly impossible. Even during the Cold War, the Soviets were able to accelerate the development of Buran due to how much information they were able to get about the US Space Shuttle. Things were far less connected and far more secure back then. Today it would be incredibly difficult to secure so much source code.
It's interesting that some municipalities copyright their laws to keep other municipalities from copying them without payment. On one hand, I can understand them seeing other places as freeloaders, benefiting from the taxpayer funded code of laws without their own taxpayers contributing to the creation of laws primarily applicable to local municipalities. On the other hand, it just seems weird for laws to restricted by copyright.
some slippery slope arguments are stupid, such as yours.
Obviously you keep personnel records private (unless there's some law/court case requiring it be open). Classified material is already classified, and is kept private regardless - but there's a good argument to be made that there ought to be automatic declassification of material after a set amount of time (perhaps 20-30 years). Declassifying material is good for the public, as the ability to audit the past prevents future abuses.
Not the parent, but I'm pretty sure that their intent is that it's the default that should be flipped. At the moment, all agencies default to confidential, and only share their work in particular cases; the proposed change would be of making all the work transparent unless explicitly classified.
As a good example of how this approach is implemented, see Gitlab, which share pretty much everything except personal data of their employees and customers.
What is the downside? I was thinking it could compromise software security, although my layman understanding is we’re better off if the open source community finds and makes problems visible?
Or there are other software secrets that we wouldn’t want state adversaries to see, like things that block your access under export control laws?
That's my first thought. The NSA and CIA probably have all sorts of in-house developed source for all sorts of evil things that they sure won't be sharing.
If agencies share code, there will be a need for coordination of changes, someone makes extra money in the process? i.e. a small contractor doesn't get the change request because only some big player can handle the complexity of a mutli-agency contract?
The government is full of cronies, this bill was passed because someone has plans to use it to screw us all over.
I’ve heard some contractors intentionally license source code they provide in a way that it can’t be reused and if it can only if they provide it to you again, so the government basically pays for the same code over and over. Even if it’s highly reusable. Maybe this will help with that?
I'd expect some tech guys in one branch wanted access to some relevant/useable code from another branch, the other branch refused for whatever reason, and we get bickering that eventually makes its way up.
I have read section four. How does it connect with my comment? I'm not sure what an automatic exemption is?
I speculated this bill may feel good, but like all things in the government, was only passed because wealthy cronies have determined it is a net good for them in the long run.
For those of you with no government experience I suspect you have absolutely no idea why this is so challenging.
The military is allergic to internal software. First of all you have to understand IT in the military is a different world far beyond your imagination because everyday they are under attack by the best nation-state cyber intrusion people on the planet. Your start up will never experience this and the mega corp, like Facebook will only just barely experience anything like this because it’s just not that important. The only commercial organizations that even come remotely close to what the military experiences daily are large financial organizations. Also, don’t forget the US military is the largest single employer on the planet, like 4.5 Walmarts.
So the military monitors everything at multiple levels. That also means locking things down to approved software lists at different levels. The people writing the security policies and/or performing the monitoring likely aren’t experienced software directors. They look at things like NPM and Maven and just see unlimited attack vectors from people who have no idea about security, and they aren’t wrong.
Then in the civilian and contractor space where do you put the code. If it’s paid for by the government then it’s owned by the government otherwise the contractor company wants to own it completely separated from the government so they can charge the government for it. Then consider if it’s a subcontractor not aligned to the financial goals of the prime contractor. Even when the government wants to do the right thing it’s complicated. As a software guy under a non managing co-prime I really don’t give a shit and say just give the government everything and it’s weird to see people try to throw up layers, especially since the government side is always less restricted because they almost always achieve vastly superior security accreditation on their infrastructure.
The depiction of the military's IT as nearly impregnable overlooks the widespread issues with outdated infrastructure and cumbersome policies that significantly impair its effectiveness.
While I'll acknowledge that certain areas within the US military might experience the level of threat and security sophistication described, the broader landscape is fraught with legacy systems that struggle to integrate modern solutions or best practices. These outdated systems/workflows/bureaucracy often result in inefficiencies and vulnerabilities rather than providing superior security.
You never hear about the US military getting broken into, not because it doesn't happen, but because it is classified when it does. Avoiding public embarrassment is the No.1 use of classification, resulting in this type of belief in their competence. I'd put Facebook ahead of the US military any day of the week, and it ain't close (who incidentally are a payment processor).
The infra for JWICS is pretty darn good. All the security failures have been at the human layers.
Somehow I am a little skeptical that knowledge of all JWICS security failures just got leaked here. :-)
> The depiction of the military's IT as nearly impregnable...
Where was this depiction made by the OP? I only see descriptions of IT infrastructure that's under attacks of a nature and scale that not even software megacorps will ever see.
> and the mega corp, like Facebook will only just barely experience anything like this because it’s just not that important.
I worked at Microsoft, and speaking to their security team my impression was that MSFT is under persistent attack from nation states on a non stop basis, up to and including working to get government assets hired to work at Microsoft to leak secrets out.
Given the importance of AWS, I have no doubt Amazon is under similar threat.
For Microsoft to be in such a position makes sense, as they provide services for both US military and government (which also includes agencies), as well as for some infrastructure services. This is a pretty unique situation, compared to most other big tech companies.
Hell, there is a whole “Azure for US Government” product out there just for that, and that’s in addition to the usual AD/OneDrive/SharePoint/Windows/etc. suspects.
I would imagine Microsoft is a bit different because of the OS. If you can hack Windows you have access to nearly every institution in the world. Linux and iOS don't have that reach. No need to hack AWS, you hacked the computer that is logging into AWS.
Why rob a bank when you can pickpocket a guy walking into the bank instead?
Anyway Linux has 62.7% share of servers https://en.m.wikipedia.org/wiki/Usage_share_of_operating_sys...
The majority of cloud infrastructure is run on Linux.
You're saying there's no need to hack Linux when it's easier to hack Windows, and therefore Microsoft has better security fundamentals as the providers of a less secure but more prevalent OS? I don't follow the argument.
AFAICT this has very little to do with the military. Quoting from the actual bill:
(A) IN GENERAL.—This Act shall not apply to classified source code or source code developed primarily for use in a national security system (as defined in section 11103 of title 40, United States Code).
(B) NATIONAL SECURITY.—An exemption from the requirements under section 3 shall apply to classified source code or source code developed—
(i) primarily for use in a national security system (as defined in section 11103 of title 40, United States Code); or
(ii) by an agency, or part of an agency, that is an element of the intelligence community (as defined in section 3(4) of the National Security Act of 1947 (50 U.S.C. 3003(4)).
I quit contracting when over the course of a year I spoke to other sec teams in my branch, around my customers branch, my local contractor network and several vendors that told me another service branch had completed my exact project years ago and “why dont you just talk to them” was met with stares from my gov customer. Then you understand the racket that is gov contracting and why things take years longer than they should.
> US military is the largest single employer on the planet
Maybe not on the entire planet? I know it doesn't matter and it's not really anything but I guess that's not USDoD. But then again who believes Wikipedia anyway https://en.wikipedia.org/wiki/List_of_largest_employers. Besides even if it's true it's barely by a whisker and we shouldn't put further wars (i.e foreign freedom distribution enterprise) past the great nation of USA so that will change on a whim anytime. Cheers.
Also if this link is to be believed then 4 Walmarts (or even 4.5) will be really a lot.
> Your start up will never experience this and the mega corp, like Facebook will only just barely experience anything like this because it’s just not that important
I guess someone who’s never worked there could say this. Facebook is a treasure trove of data for details on domestic and foreign politicians.
The MoD of India is larger, fyi.
I assumed it would be much larger, but it's a fraction of a percent larger:
https://en.wikipedia.org/wiki/List_of_largest_employers
That's actually kind of shocking to me given the difference in population between the countries.
Indian MoD 200,000 civilian employees, US DoD over 700,000 civilian employees - that's the part where the difference you'd expect shows up, not in the raw number of soldiers.
It shouldn’t be that shocking, the United States is the only country able to project military power globally. India can’t even provide basic sanitation for all of its citizens.
Poor countries can have enormous armies. The PLA during the late 1970s had like 5 million people in the ground forces alone. They have since cut that number by over 2/3 as they modernized.
Thanks for pointing that out. I had no idea.
>They look at things like NPM and Maven and just see unlimited attack vectors from people who have no idea about security, and they aren’t wrong.
Then what do they do? Aren't there tools to check for security vulnerabilities in the market like Sonar Qube? Wouldn't (or couldn't) the millitary run a beefed up version of that and developers can't check in code without ensuring 100% compliance to security vulnerabilities
They use approved software lists containing a list of software that is already approved, by vendor version number, for use within your organization. There are teams that analyze popular commercial software for approved usage, often including source code inspection. Bank of America does the same thing.
Tools like Sonar Qube are pretty shallow. Anecdotally, a robust development process will produce software that always reads clean on those scanners even if those scanners are not part of your development process. They detect defective development processes more than they detect defective code or designs.
Parts of the US DoD do have more rigorous testing that is considerably broader in scope than commercial linters and such, and evaluates for threats that commercial systems don't consider. Many of these tests reliably break open source software. It is unclear how thorough or exhaustive these audits or tests are -- it can be quite opaque. For good or bad, having been through several serious security audits by multiple organizations, my software always came back clean so it is difficult to calibrate their sensitivity from the outside.
I'm not sure what the military does, but automated scanners will never be a panacea.
And I encourage open source devs who get security compliance demands without patches or significant collaboration to ban the person filing the issue.
Haha, very true. It is insane how demanding and toxic some “developers” can be towards opensource creators and maintainers, as if they own them.
But on the other hand, open source or giving things out for free for people to try out and use is also a great way to find interesting friends who just want to build cool stuff together, and make new friends along the way :D That part is prolly the only reason why I like opensource so much, it attracts certain kinds of interesting people depending on the project you’re working on.
Look at JVM exploits from the last years. They're usually chains of quite clever hops, for example from a serialisation or deserialisation vulnerability. Sonar is not going to help you with that and when something like it pops up it might already have been used 'in the wild' for some time, and then you have the problem of rolling out patches into the field.
You'd be better off going back to Ada.
> JVM exploits from the last years
Entirely user/library serialization or fine cryptographic issues, and not the VM, no?
Lots of audit and compliance tooling exists. What happens is they turn on a new datacenter, get 150k vulnerabilities, and then try to address them one by one. There's a lot of dead weight and incompetence in government IT.
>>>Your start up will never experience this and the mega corp
You writing this makes me believes you don’t work around or with the IC and speaking out of your lane.
I don't provide dedicated security services to start ups, so maybe I am outside my lane. However, it is my baseless assertion that nation-states are not dedicating entire teams and months of social-engineering research to backdoor a startup for non-monetary motives. I also suspect startups do not own the entirety of their own distribution infrastructure in production from the wheels, through the ISP, to the local keyboard.
The US Army at least uses Azure and AWS govcloud and not their own infrastructure. I don't think this takes away from your points though, the infrastructure is very locked down and meticulously managed and approved.
It's not one or the other, they use both third party cloud and a lot of their own infra.
Its very likely any given startup will not be attacked by nation state backed hackers continually, 24/7 365. I don't think this is off base at all.
>>> it’s very likely any given startup will not be attacked by nation state backed hackers.
On what assumption do you base this? Startups that have high research value don’t hit your radar as a target?
And Really? Any given startup? Also the OP used Facebook.
I am baffled at your sense of security in nation state activity. Read the 2012 annual report to Congress about China. They collect everything.
You’re misunderstanding.
Resources even for nation states are finite. At minimum attention is a finite resource that limits ongoing operations. Active high value targets make sense: defense, infrastructure, finance and even to some extent media.
With that in mind, do you really think they’re interested in a startup that optimizes Google ads? Or how about postgres as a service with no clients of interest?
It’s not that I feel a sense of security but the low success rate script based attacks aren’t what I’m talking about here (or for that matter things like perpetual port scanning of the internet. Every entity seems to do this looking for holes), we are talking about active operations by skilled attackers. There is only so much of that to go around.
> ...I really don’t give a shit and say just give the government everything and it’s weird to see people try to throw up layers...
Yeah, this always struck me as so strange. I worked at a contractor where our customer really did own all of the deliverables, but I had peers who worked at contractors where that wasn't the case. To them, I was all like, "Guys. Our tax money is paying for this. Why are you rooting for pulling money out of everyone's pocket to massively enrich a few fat cats and sales guys in your company?".
Like, if you're of a "We're not going to give everything to the government" persuasion, then the reasonable way to handle that is to give the government the deliverables to do anything they want with, just so long as you're free to sell the unclassified components of it (and things derived from them) in the private sector to interested parties without interference.
I've seen it where development happens under one Customer, then a few years later they get some bad management and flounder, then a new Customer team (or teams) has pretty much the same mission. It's nice to be able to carry what you've already done with you vs starting over.
The Defense Sector is very much like the private sector in that it has hundreds of companies/teams doing pretty much the same thing.
> Under the law, agency chief information officers are required to develop policies within 180 days of enactment that implement the act. Those policies need to ensure that custom-developed code aligns with best practices, establish a process for making the metadata for custom code publicly available, and outline a standardized reporting process.
> Per the new law, metadata includes information about whether custom code was developed under a contract or shared in a repository, the contract number, and a hyperlink to the repository where the code was shared.
Sadly it doesn't sound like the law requires agencies to make the code publicly open source, it just requires inter-agency sharing (bill full text [1]). They only need to share "metadata" publicly.
[1] https://www.congress.gov/bill/118th-congress/house-bill/9566...
> Sadly it doesn't sound like the law requires agencies to make the code publicly open source, it just requires inter-agency sharing
This is a good first step. The next would be sharing with states, municipalities and universities. Public sharing disperses a lot of IT responsibility that presently doesn’t exist.
And they will eventually learn that it's easier to share with the public at large than with a neighboring department.
At least that's my experience in a commercial setting: it's easier to publish something without restriction than to share it with a specific hardware or software partner only. The latter creates all kinds of questions around neutrality, applicability of NDAs, licensing, and so on.
Yes it is better than NOT sharing!
What would be more interesting is to require all private companies who are doing US government contracts, especially the ones who are handling classified projects to do the same as these US agencies!!!
Gov-acquired software can be architected to separate open-source components from classified components. This enables reuse of commercial (open or closed) software with the economics and rapid iteration of larger markets. For open-source components, this enables public collaboration on COTS, with non-public collaboration on classified GO(v)TS components.
Pretty sure this is how BRL-CAD works, most of the software is open source, but there are a few classified extensions not released.
Thanks for the pointer, https://en.wikipedia.org/wiki/BRL-CAD
> The BRL-CAD source code repository is the oldest known public version-controlled codebase in the world that's still under active development, dating back to 1983-12-16 00:10:31 UTC.
Who is going to pay for this?
It's practical for software vendors on platforms [1] with virtualization, which have been gradually increasing over the past decade, including Windows, ChromeOS and Android.
[1] https://www.intel.com/content/dam/doc/case-study/enterprise-...
I'm a little lost, but it seems like you aren't - how does virtualization help with the actual work of splitting codebases into reusable components?
It doesn't help with doing any splitting (e.g. 20 years ago) but in current era where software is architected as micro-services and packaged for containers and VMs, software is more likely to be "born as reusable component".
This is beautiful, do you think we might be going in such a direction?
I feel like the posted headline makes that sufficiently clear.
I get suspicious any time the word "best practices" appears, because it's likely to just encourage more bureaucratic cargo-culting.
I don't know. For a start, a working bureaucracy would tell you that you must use the term “recommended practices” instead.
Yes. Always interpret "best practice" as "what you won't get fired for doing".
I've signed many contracts with this clause. I've always interpreted it as "if you post what you did on HN and everyone responds saying you clearly shouldn't have done that", then it isn't best practice.
I mean, it’s not like we’ve ever seen this with the agile movement /s.
I’ve gone through “agile transitions” in government contracting, at a high level it starts out with a high concept idea of reducing lead times and increasing productivity. Then directives get handed down through layers of management, the decision is made to adopt Scrum or SAFe™, that gets handed down to middle management, who tailor the process in ways that specifically benefit themselves, and you end up with waterfall done poorly and with extra steps™.
What will happen is that there will be very loose definitions of source code and flexible definitions timing when code is released. If an agency does not want to share, they’ll find a way to evade, and still check off the box.
Sure, but won't there also be some agencies who voluntarily implement sharing in the spirit of the law? And won't that be positive for them and their dept's reputation?
Most DOE contracts (the ones the government has with the university or consortium running the lab) usually say something to the effect of “unless you can prove this source code is marketable/SBIR worthy, you can keep it private or open source it (but not under the GPL). There’s exceptions, but the reasoning was also there to say that _other_ contractors should retain the ability to modify source code and similarly not release it (presumably defense was my guess).
So the bar has been high to keep it private for $$$ reasons, but you could always keep it private for any other reason.
DOE Code is the program that ostensibly tracks the open source software, usually just through github organizations. OSTI is the division that tracks all IP and research.
> IN GENERAL.—This Act shall not apply to classified source code or source code developed primarily for use in a national security system (as defined in section 11103 of title 40, United States Code).
The exemptions are extremely broad in section 4 of the act. I don't expect anything interesting to come of this reporting. Or for any money to be saved.
And I imagine there will likely be a sudden increase in the number of classified software projects and national security systems in the next 180 days. This may very well be another case of a law trying to make things better, but ultimately having the opposite effect.
Some things, like ZFSOnLinux are already shared publicly. The repository is now the OpenZFS repository and it has made many people's lives better. I know it has made my life easier. The open source development model benefited LLNL, which got a much better code base than they would have developed on their own. :)
There are other things already shared publicly like NASA IKOS:
https://github.com/NASA-SW-VnV/ikos
That one gets far less attention from third parties than it should. If it could be developed into a general purpose sound static analyzer that handles multithreading, it would help to improve many other projects.
It also doesn't require agencies to do anything since some agencies have more power than the government and government law is thus irrelevant to them.
Example: Snowden revelations.
Even worse, it requires establishing new policies and staffing enforcement. They'll need to throw bodies at this effort, and so people building sytems will have even more pesky forms and policies and permissions to deal with. This will add cost and have very little, if any, positive impact.
This is typically the “smart but cynical” position I hear from some bureaucratic actors and those who aspire to become like them.
It’s the sophisticated version of “Don’t attempt any change” brigade’s position.
My observations from a lifetime in very large, cumbersome orgs is that improvement only comes from change and in highly dysfunctional, low-performance and low-ambition environments almost any reasonable change, supported by a really tiny number of engaged participants with a clue, leads to outsized positive step changes.
Even better, doing this as a sustained, tide-coming-in approach over several years can create more engaged people with a clue and slow transition to high-ambition, moderate-to-good performance cultures.
It’s worth the effort if you’re not doing it alone, and know that all the attempts pay off as part of a cumulative push. It changes lives both in the service delivery org, as well as those they’re supposed to support.
Sounds like you came through frustrated cynicism yourself to a kind of enlightened optimism and want to call it realist. I really appreciate this point of view and I'd like to get there myself, but here's the rub:
> tide-coming-in approach over several years
This phrase does a bunch of work, and seems to almost agree with the cynical perspective that individual small positive changes (or the more common failed attempt at the same) are futile. But if the difference between optimism and cynicism was only a matter of being patient and persistent, then we should be able to observe things getting better over time in a relatively consistent way.
Is that happening? Honest question, what large organizations can we point to that are better or more effective than they were 5, 10, 50 years ago? (And: for any situations where improvement happened, was it really a tiny number of engaged participants doing bottom-up change, or was it top-down change by some kind of executive decree?)
Youth without perspective will have a hard time answering maybe, but if the youth and wise old heads are both trending cynical at the same time then maybe the cynical position is actually true, and patience/perspective are simply not as relevant as the optimist would hope. My own experience is probably somewhere between youth/wisdom, and I tend to avoid large orgs as much as possible! But as an outsider, it looks like large orgs are all dysfunctional by default and only get more dysfunctional over time, with or without external pressures forcing that situation. Maybe there's a bureaucratic version of the laws of thermodynamics at work here.. the phenomenon of entropy isn't really cynical or optimistic or pessimistic after all, it's just the way things are.
Some people jump early. I’ve stayed long enough - or returned later on request after doing a startup - to see whole orgs and product lines in telcos (!!), banks (!!!) and even government agencies (yeah, wasn’t really expecting that tbh) getting structurally better over time due to concerted effort of a relatively small group of folks.
I’ve been part of turnarounds where senior execs have said that the three hundred people here will lose their job if nothing changes. I still talk to some of those teams that transformed themselves and others, and made it.
So I tried (!) campaigning for a full OSS model (https://web.archive.org/web/20200920095030/http://oss4gov.or...) based on the idea that public money means public shoukd see what comes from the money.
To me the default for any government software should be OSS unless ministerially signed off.
But I was young and naive
I don’t think that’s so controversial, neither does the UK government - https://www.gov.uk/service-manual/technology/making-source-c...
This was starting sometime in 2010, as gov.uk was gearing up IIRR, plus most people you talked to at the time in local government would just stare and not have a clue about open source. We have honestly come a very long way (I reckon we do a “generation” each decade - making me a third time around )
However - as always, we have not come Far enough
FSFE shares your opinion across the pond: https://publiccode.eu/en/
I've worked at military contractor jobs for years, and there are many people there who believe this - if the taxpayer is paying and the software isn't classified, then it should be open source.
Ghidra is a great example of this, and having this software be free has been of great benefit to the security community.
We create open-source software and attempt to get government agencies to adopt/use it. It's crazy how alergic these agencies are to open-source. Some will even create their own, with legacy style implementations (csv uploads, broken parsers), complete with bugs/flaws that are predicatble rather than use someone elses code.
When responding to RFPs, the open-source stuff has an a higher level of scrutinty than the closed systems. Like, if it's open then you have to show it's good but if it's closed the vendor just says "yep, we are perfect" and the agency could move on. It feels like the agency, and the employees don't want any responsibility. But I've never seen anyone lose their government job from some incompetence.
You can't hold anyone accountable for open source. With closed source, there's someone else to point the finger at when things go wrong.
I heard this a lot before I started my career but IME this rarely pans out and you’re just stuck with broken software without documentation and source code.
yep. usually the original architect moves on to another project before things get really bad. and then all that's left is the bag-holder (me).
>>>It's crazy how allergic these agencies are to open-source.
It’s about job protectionism on the greater scale and being the subject matter expert who leverages his code base for promotions on the individual scale. generally agencies do not view each other as working for the same team. It can be very competitive when lobbying for resources from congress for your agency.
I work in gov and speaking from first hand knowledge. The culture is toxic. It’s broken and I can’t wait to see what changes Elon and trumps team propose.
hopefully a different approach than with twitter
U.S. DoD has an FAQ on open-source software, http://dodcio.defense.gov/OpenSourceSoftwareFAQ.aspx & https://github.com/risacher/DoD-OSS-FAQ
> This version is being posted to GitHub as an experiment in collaborative tools for public engagement of government policy documents. Suggestions for changes or additions to this document by military or civilian personnel, contractors, and private citizens may be submitted as pull requests..
(2010) https://www.youtube.com/watch?v=WWt0YiXcEkE
(2024) https://openssf.org/press-release/2024/10/29/openssf-expands...Good intentions but I don’t expect much to come except contractor 1’s would-be competitors closing the gap or using this to throw stones based on existing contract code quality. It is easier to write code than it is to read code!!
> I don’t expect much to come except contractor 1’s would-be competitors closing the gap
That means increased competition and reduced costs for the government.
> or using this to throw stones based on existing contract code quality
That means code review, which results in improved code quality one way or another.
I fail to see the problem here.
That’s cool. These are my expectations. Company 1 wins contract and builds something, key team members are experienced with making and navigating the “process”. Company 2 copy/pastes. They have not performed any work yet but they entered a bid X years later and bring up the years of “mediocre” dev Company 1 has done. There is only existing company 1 work and only hope of company 2. Contracting Officer chooses company 2 because promises sound good!
Reality, company 2 wins on cost and doesn’t understand the context of what was built or the environment it was built in. They don’t understand the costs as they didn’t pay them. Company 2 quickly proposes “full rewrite!” Lower cost labor they brought in can’t perform and quality degrades till we have (insert Gov software program here).
Or it doesn’t happen.
Ideally, a body such as NIST would become the stewards of federal libraries that contractors are then compelled to use and improve. If the end goal is about cost efficiency more than any other ideal or objective, then that type of centralisation and reuse should be promoted and enforced.
I'm not familiar with US government procurement, but the way public tenders for software work in the EU, this isn't that likely to happen. You need some serious references to even qualify for most tenders, especially the kinds that this would be a problem for. Without serious corruption, you're not getting it. And with serious corruption, having seen the code won't make a difference.
Organizations often make a few missteps before figuring out what works. Some amount of failure is to be expected when doing anything on the scale of a nation. At least if everything's open, each attempt has the opportunity to learn from the last and can be evaluated on it's merits in comparison. It's also likely that other organizations will find some of the software useful.
I was really sad when people sued the NSA over developing Accumulo[0].
[0]: https://www.techdirt.com/2012/07/18/senate-not-concerned-abo...
This is great. I’ve spent some time working with gov teams where this is recommended practice [0]. In many cases though codifying as a requirement is still needed for that recommendation to be followed. This is particularly true for those who have not been part of OSS community before, which is common in public service.
As others have highlighted, public funds should lead to public good and open source is a great way to increase that benefit.
[0]: https://www.forgov.qld.gov.au/information-and-communication-...
Awesome. I remember the pain of not even being able to read code within one and the same organisation, stuff like this I imagine will make work easier for anyone who builds top-down mental models.
This is great.
In my country agencies use code as trade like "i will give you the code to generate holograms to by pass video KYC and you will give me men power to spread fake news".
Because there is no sharing, agencies spend a lot of money developing multiple versions of the same need, not all with great success. This bill should take you further in terms of quality and advantage.
"The new law doesn’t apply to classified code, national security systems or code that would post (sik) privacy risks if shared."
What sort of code would pose privacy risks if shared? That sounds like some nasty intermixing of code and data.
No real risks, but this gives them a convenient excuse not to. I've had companies and government agencies refuse FOIA requests for technical documentation on privacy grounds because "it applies to a system that processes personal information", with some adding that "knowing the inner-workings of the system would lead to a likely compromise of the system".
Yes, government contractors will gladly admit between the lines that their code is garbage and they largely rely on security through obscurity. And the information comissioner has agreed with them a few times!
> "The new law doesn’t apply to classified code, national security systems or code that would post (sik) privacy risks if shared."
Ironically, it's "sic", not "sik". Muphry's Law got you when you weren't looking. ;)
Muphry's Law:
"If you write anything criticizing editing or proofreading, there will be a fault of some kind in what you have written."
https://en.wikipedia.org/wiki/Muphry's_law
>Muphry's Law
EDIT: TIL this is a law of its own. Happy New Year!
Any sufficiently custom code will have features that give away a lot of information about the subject matter.
As an example, think about what you might see in Excel formulas.
There's no difference between the two.
> ...collaborative software companies Atlassian and GitLab Inc. backed the legislation.
lol :)
I wonder how this works for defense/law enforcement agencies. Do they get some special carveout?
> The new law doesn’t apply to classified code, national security systems or code that would post privacy risks if shared.
Seems pretty clear they would.
Ah, thanks! Missed that.
That's stated in the article.
This article references "custom code." What about custom applications?
Are all government contractors required to provide the source code for all developed applications? Or does this bill only apply to contracts where the deliverables actually include source code?
It’s hard to know what they hope to accomplish with this bill. Anytime you develop custom code, it’s because you need something, well, custom.
What are the chances that something custom built for one agency is going to be at all useful to the custom needs of another agency?
Almost 100%. Most 'custom code' I've written in my career for various employers, customers, clients, etc has been very similar.
Business logic tends to be <10%, the rest is just integrating stuff and piping data.
You would think some "glue code" around their databases could maybe be shared, or eventually converge. How they handle forms? Something.
by arguing the need to be sharing code (despite it not being the logical thing to do), you end up with (sub)contractors who will have more work to do to comply, and to make an otherwise simple system more complex by virtue of having to shove two separate systems together in one, so that they could be shared between agencies!
> by virtue of having to shove two separate systems together in one, so that they could be shared between agencies
Where does the bill require interoperability?
Might not be directly useful to most people but for AI companies looking for more material for their LLMs to consume, it would be a goldmine.
I think you're confusing share (make available) with share (mandatory reuse).
Sharing source code isn't enough. The right people need to be aware of its existence at the right time. For instance, there needs be part of their governance that due diligence be performed prior to executing a contract.
Does it apply to the FBI, NSA and CIA?
Wow. Some rare good news from the US government.
unless this is just an easy money grab for billions in contractors, with senators who own the businesses, to work as hard as possible at non-compliance
Yes, a thing is not a thing if it’s something entirely different.
Or AI companies looking for more LLM feed material.
This would have been useful to me 10 years ago when I was trying to get my hands on Ghidra within channels.
4(a)(1)(B) NATIONAL SECURITY.—An exemption from the requirements under section 3 shall apply to classified source code or source code developed—[...](ii) by an agency, or part of an agency, that is an element of the intelligence community (as defined in section 3(4) of the National Security Act of 1947 (50 U.S.C. 3003(4)).
https://www.congress.gov/bill/118th-congress/house-bill/9566...
Deloitte in shambles
I would like to see this go further. Have publicly funded universities develop "enterprise" government software such as DMV or other agencies, completely FOSS, and each year have a public hearing where the CEOs of the private contractors that currently provide this software can explain why, exactly, the FOSS version isn't good enough to replace theirs.
Generally speaking, anything and everything paid for with taxpayer dollars should be made public. Public Monies Public Goods should be the absolute basis.
That's already the rule, but the DoD is the only agency who takes it seriously (examples are BRLCAD and FalconView).
This doesn't stop unscrupulous contractors from copyrighting code and charging license fees (see: most DoE code, with exceptions like NWCHEM). I've often wondered why this hasn't resulted in any lawsuits; I suspect the reason is that nobody really cares.
Were you also afflicted with FalconView? My condolences.
I'm not going to claim it was fun, but it sure beat using one of those standalone nav calculators!
> That's already the rule
Do you know what law requires it?
There was some encouragement in the 2018 NDAA, https://www.meritalk.com/articles/gao-dod-not-fully-implemen...
> The report notes that the 2018 NDAA mandated DoD establish a pilot program on open source and a report on the program’s implementation. It also says that OMB’s M-16-21 memorandum requires all agencies to release at least 20 percent of custom-developed code as open-source, with a metric for calculating program performance.
It's 17 USC 105. Most agencies work around it by hiring contractors, which then leaves the copyright in the hands of the contractor. It's a loophole I'd like to see closed.
Are the copyright provisions in govt contracts similar or different to civilian contracts? And does that vary by state much?
Also, do govt software contractors worry much about AIs being trained on their codebases, attribution, etc.? Would that increase under this law?
It depends on the contract. In the DOE system it's usually national lab employees working under direct funding; in that case the operating contractor retains copyright. In the DOD world it's more common for development to be actual USG employees, in which case there is no copyright and the software is public domain.
None of this applies to state or local government: 17 USC 105 applies only to federal matters.
Attribution tends to be important to DOE people since they're usually academics working in the purview of Office of Science, and citations are how they get promoted.
I don't think anyone worries about AI training on their codebases, since LLM providers are not held accountable to any copyright enforcement anyway.
You misunderstood my point about govt software contractors needing to worry about AIs being trained on their codebases: for their job security, automating and replacing them. Specifically, if the govt tries to do the same things we see in commercial SW devpt.
(Not copyright claims against commercial LLM companies).
I don't think anyone in that space really worries about being replaced by AI, because it's not really up to the task of replacing anyone.
If that were implemented at lower levels of government, it could increase costs for some while reducing it for others. If you're the State of Kansas and want to have software written for management of toll roads and toll payment accounts, you can spend a bunch of money developing it yourself, and then other states can freeload off your work. Or you can contract it out. If that contractor can then sell that same solution to other states, they can offer a lower rate to Kansas. But if they have to make their code available to all, they'll have to charge Kansas the full cost of development. If you're Nebraska and want to do the same thing as Kansas a few years later, you get a benefit from the spending Kansas has already done. Nebraska wins, Kansas loses.
It's more common for state governments to join forces to define standards for data, performance, features, and interoperability, and then require contractors to comply in the contract language.
I'm not aware of many contracts for bespoke software in the state government space; it's far more frequent that someone identifies a need and then develops a solution to bring to market.
Sorry no. Because China. The US gov should be keeping their code, including their shitty overpriced contractor shit-code, private.
The United States is a primarily open society. Keeping something as easily transportable as source code from another nation-state is nearly impossible. Even during the Cold War, the Soviets were able to accelerate the development of Buran due to how much information they were able to get about the US Space Shuttle. Things were far less connected and far more secure back then. Today it would be incredibly difficult to secure so much source code.
It's interesting that some municipalities copyright their laws to keep other municipalities from copying them without payment. On one hand, I can understand them seeing other places as freeloaders, benefiting from the taxpayer funded code of laws without their own taxpayers contributing to the creation of laws primarily applicable to local municipalities. On the other hand, it just seems weird for laws to restricted by copyright.
So everything from classified material to office memos and personnel records? That's not gonna happen.
If you, at home, pay someone to do work, what exactly do you own beyond the end product?
some slippery slope arguments are stupid, such as yours.
Obviously you keep personnel records private (unless there's some law/court case requiring it be open). Classified material is already classified, and is kept private regardless - but there's a good argument to be made that there ought to be automatic declassification of material after a set amount of time (perhaps 20-30 years). Declassifying material is good for the public, as the ability to audit the past prevents future abuses.
This is a strawman.
Not the parent, but I'm pretty sure that their intent is that it's the default that should be flipped. At the moment, all agencies default to confidential, and only share their work in particular cases; the proposed change would be of making all the work transparent unless explicitly classified.
As a good example of how this approach is implemented, see Gitlab, which share pretty much everything except personal data of their employees and customers.
Disagree with that in the case of software.
Why?
You provide a convincing argument. My mind is changed.
What is the downside? I was thinking it could compromise software security, although my layman understanding is we’re better off if the open source community finds and makes problems visible?
Or there are other software secrets that we wouldn’t want state adversaries to see, like things that block your access under export control laws?
I expect secrets to be shared in that code and data breaches to follow (not that they wouldn't anyhow...)
How does this affect exploits?
From the article:
> The new law doesn’t apply to classified code, national security systems or code that would post privacy risks if shared.
That sounds like a security nightmare. A single accidental exploit in one agency could easily spread to others reusing the same code.
Now, imagine if that exploit was instead intentionally planted by a foreign spy, targeting common use cases...
This is just another form of the "security through obscurity" argument used against foss in general. Many eyes make all bugs shallow.
That's my first thought. The NSA and CIA probably have all sorts of in-house developed source for all sorts of evil things that they sure won't be sharing.
Any idea what the definition of "source code" is? I'm wondering if low-code workflows would count.
A worthwhile law, but I have been there many times in the corporate world with various departments required to do the same.
Just saying it (passing a law) will not make it happen, it will require a lot of work on everyone's part. I wish them luck.
Well, it will allow code inspection by some agencies... but the "re-use", forget about it.
Couldn’t source code be requested under FOIA? It’s technically a government document.
Yes it can; I've done this in the past.
Imagine all the interesting code that will come from the NSA.
Someone didn't read the link.
What's the cynical scam angle for this bill?
If agencies share code, there will be a need for coordination of changes, someone makes extra money in the process? i.e. a small contractor doesn't get the change request because only some big player can handle the complexity of a mutli-agency contract?
The government is full of cronies, this bill was passed because someone has plans to use it to screw us all over.
I’ve heard some contractors intentionally license source code they provide in a way that it can’t be reused and if it can only if they provide it to you again, so the government basically pays for the same code over and over. Even if it’s highly reusable. Maybe this will help with that?
I'd expect some tech guys in one branch wanted access to some relevant/useable code from another branch, the other branch refused for whatever reason, and we get bickering that eventually makes its way up.
Any informed specilation on which branch wanted to use which branch's code?
Read section 4 of the law, especially the automatic exemptions. Lots of stuff isn't covered.
I have read section four. How does it connect with my comment? I'm not sure what an automatic exemption is?
I speculated this bill may feel good, but like all things in the government, was only passed because wealthy cronies have determined it is a net good for them in the long run.
What connection am I missing?