The US government’s SHARE IT Act became law in December 2024, requiring that all custom-developed software be accessed, shared, used, and modified governmentwide. By allowing any federal agency to access and use the code, the SHARE IT Act ensures that the investments in custom-developed software ($12 billion spent annually) are maximized, reducing the need for each agency to develop or contract for similar software independently. Agencies are not only mandated to share their custom-developed software with one another but are also empowered to modify the code to better meet their specific needs. This capability to tailor and enhance software without starting from scratch is a boon for rapid, cost-effective technological advancement within the government.
The SHARE IT Act Puts Pressure On Quality Coding Practices
According to the SHARE IT Act, agencies have 210 days from enactment of the law to ensure that all custom-developed code and corresponding documentation, data models, schemas, metadata, architecture designs, configuration scripts, and artifacts required to develop, build, test, and deploy the code are: 1) stored at not less than one public repository or private repository; 2) accessible to federal employees; and 3) owned by the agency. This means that US government agency software developers and leaders must follow best practices for shared code and:
Double down on security and governance. Double-check that static application security testing and dependency updates run regularly on the project and mandate. Monitor the software bill of materials using software composition analysis solutions to detect newly disclosed vulnerabilities for any open-source code that the software relies on. When making an agency source code public, consider using the OpenSSF GitHub action to ensure that your project meets baseline security standards. Government agencies have found success in establishing an open-source governance program office such as the one established by the Centers for Medicare and Medicaid Services.
Influence project direction. Government program offices likely won’t have significant influence over the direction of large custom-development projects, making alignment with specific needs challenging if you are expecting a full solution out of the box. That said, it is important that your developers understand and contribute to the custom-development projects you rely on. Make it a goal to fix security issues and quality defects. In the event that a critical vulnerability is discovered, the developers in the community will be the first to know and your team can help with remediation efforts.
Take into account interoperability and integration risks. When evaluating project reuse, be sure that your developers are able to understand, extend, and maintain the code to meet your agency’s needs. Reach out to the repository owners and maintainers to let them know that you will be utilizing their project. They can be an invaluable resource should you run into challenges integrating the code with other systems. Interoperability with legacy architectures can lead to costly integration challenges. Implementing a platform such as Dapr (distributed application runtime) within your technology stack will change the optimal methods for developing applications.
The SHARE IT Act paves the way for a more interconnected, efficient, and innovative federal government by leveraging the full potential of custom-developed software if implemented properly. To dive deeper into how to build a foundation for using shared custom-developed code, read the full reports on assessing open-source viability in government projects and The Forrester Wave™: Software Composition Analysis Software, Q4 2024. Set up a guidance session with Janet Worthington and Devin Dickerson to discuss in detail.
