What It Takes to Ship Software in Government

Unlike the private sector, the government must follow regulations from Congress when it comes to shipping software. What has become the norm in startups — like shipping code multiple times per day or signing up for a cloud service to quickly test it — doesn’t work the same way.

The government regulations are cryptic. It took me the good part of six months to figure out everything needed to ship a simple website. I hope that if I can explain how government ships software, the next wave of innovators in government will improve both the process and security of government digital services.

Let me break down the key components to shipping software in the United States government.

Privacy

The government takes privacy very seriously. While Google and Facebook are off shopping your data to advertisers, the government ensures that none of its agencies violate your confidentiality nor compromise your identity.

While there’s no clear federal law on privacy policies, we’ve all agreed that it is good practice. Many states do have very strongly worded privacy laws, like the State of California. You’ll find that most federal websites have a privacy policy. If there’s information collected from the user, then the Paperwork Reduction Act kicks in (see below), and there’s additional disclosures that must be made about “Routine Uses of Information.” This part is dictated by the Privacy Act of 1974.

It is a common myth that “the government” knows everything about you.
It is against the law for government agencies
to share information without your approval.

Federal government agencies are prevented from sharing your information. If you’re worried that your IRS tax return information will be available to the Department of State when you apply for a passport, don’t worry. You have to explicitly give each agency permission to share your information with another agency. Of course, this all goes out the window in cases of National Security.

The other exception is if the agency specifies the use of data collected as a “routine use.” Agencies are required to put this in their Privacy Act Statement which appears every time information is collected; no exceptions. Here’s the Privacy Act statement for HealthCare.gov.

If you collect and store information, you must publish a System of Records Notice in the Federal Register that describes how the data is stored, what privacy controls are in place, and when the data is shared. This is also where the “routine uses of information” is disclosed to the public.

The Federal Register is a little known part of the government. But it is responsible for everything from privacy disclosures to announcements about campground closures. And it is still published in 3-column, impossible to read tiny font PDF.

Section 508

Accessing your government on the web is something that we hold as a right for all Americans. Due to disabilities, some people aren’t able to interact with websites unless they provide accessibility. The Section 508 Amendment to the Rehabilitation Act of 1973 — known simply as just Section 508 — is the law that governs accessibly for government websites.

Let’s start with an example. Can you read the text in these images?

An example of bad contrast violating Section 508 from va.gov

You can see how it would be taxing to read dark blue text on a black background. Section 508 isn’t limited just to bad color choices. It includes making sure that images have text that describes them (in case you can’t see the image) and only using controls that can be accessed by people with mobility impairments.

Section 508 isn’t just the law, it is good sense.

One of my favorite stories is from the Government Digital Service in the UK. People with disabilities couldn’t pick elements from a SELECT box because the elements didn’t resize with the webpage. So if you made the text on the webpage bigger, the browser doesn’t make the options bigger too. Whoops. Read the full user research, it is fascinating.

I now find myself scoffing at websites with horrible contrast patterns, even though they’re not government sites. I also use HTML_CodeSniffer, although there’s many good tools out there. Install one in your browser.

Security

All websites must adhere to the Federal Information Security Management Act, last updated in 2002. Yes, the last update to security guidelines occurred 13 years ago.

In order to put an application on the web or launch a website, the security requirements from FISMA must be verified. The law itself is pretty short. It basically hands over the authority to the National Institute of Standards and Technology (NIST) to dictate which security controls must be implemented in the government.

NIST breaks down systems into low, moderate, and high impact information systems. In other words, how bad would it be if someone were to break into a system classified as low? It shouldn’t be too bad. But breaking into a high system means the compromised data may result in stolen identies or a breach of national security.

The infamous NIST publication 800–53 describes all of the hundreds of security controls in 462 pages of gory detail. In a PDF document, not in a machine readable format. And not in the form of tests, but rather as verbose specifications.

To launch a simple website in government, you must manually verify hundreds of security controls from the National Institute of Standards.

When your application code changes, you must repeat the verification process for each of the security controls. Verification of hundreds of manually tested controls is then manually written into another document, called the System Security Plan (SSP).

In an ideal world, these controls would be automated as tests in a continuous integration (CI) environment. Imagine a world where the SSP is automatically generated and tracked by the CI and cloud services infrastructure.

When I started in government, we were using contractors that ran data centers who would manually deploy your code. You’d have to open a ticket, show that you met the requirements, and then wait (often days) for them to get to it. By the time I left, we were using Amazon Web Services (with IAM and audit logs) and Cloud Foundry where we could set up and tear down applications in real time. The next step is adding the security approval process (such as ATO) into the automated workflow.

Even with all the security controls verified, I’d hardly say that the system is secure. There’s currently no mechanism in government to employ white box or black box testers. There’s no reward for bugs or vulnerabilities. There’s no review of the code inside an application, other than a basic automated text scan for the word “password.” Security controls cover the basics of the system and infrastructure, but no developer would feel confident that it covered the security of their application.

Other Important Stuff

It deserves a post in its own right, but I’d be remiss if I didn’t mention the Paperwork Reduction Act (PRA). PRA was originally envisioned as a way to cut down the burden that the government places on its people. If we reduce the amount of paper that people have to fill out, they’ll spend less time interacting with government and thus more time being productive members of the economy. In reality, PRA requires feds to get permission before doing user research (with more than 9 people), sending out surveys or questionnaires, or asking people for information (like the CBP form when you enter the United States or when you apply for a government service).

Another fun but silly thing is the “Linking Policy” you see on the bottom of every federal website. The reason for the Linking Policy is to ensure that users of government websites are only linked to high quality, approved information. And if that user is leaving a government website for somewhere else on the Internet, we should make it clear that the destination is not a government website nor endorsed by the government — because you couldn’t figure that out for yourself. Written in the George W. Bush era, OMB Memo M05–04 puts this requirement on federal agencies.

Net Net: Shipping software is hard

Launching a web application (or even revising an application) has intrinsic controls in place to protect privacy and security. But these very controls are what slows down the pace of innovation in government. These controls also cripple the ability for government to be responsive to its people.

Here’s a checklist of things you need to ship software in government:

  • Authority to Operate (ATO) — A signed piece of paper from an official deemed authorized by an agency that says you can go live to the public.
  • System Security Plan (SSP) — The plan reviewed by the agency official that documents how you’ve addressed the FISMA security controls.
  • Federal Information Security Management Act (FISMA) — The regulation that, together with NIST 800–53, specifies the security controls you must have in place.
  • Paperwork Reduction Act (PRA) clearance — Required if you intend to ask the public any questions, like your name, address, or phone number.
  • System of Records Notice (SORN) — If you collect and store information, you must publish a System of Records Notice in the Federal Register that describes how the data is stored, what privacy controls are in place, and when the data is shared.
  • Section 508 — Run one of any number of accessibility tools to make sure the website can be accessed by people with disabilities.
  • Privacy Policy — Every website must have a privacy policy. If information is collected from the user explicitly, then PRA clearance must be approved, routine uses must be published in the Federal Register, and there must be a Privacy Act Statement next to every data collection.
  • Linking Policy — Every website that launches to external websites must tell you how you’ll know you’re no longer on the originating government website.

And when you’re all done, you may even get a Presidential cupcake as your reward. Who doesn’t like cupcakes?

Better or worse, these are the guidelines for keeping data safe, confidential, and secure. The information technology procedures in place are mostly legacy from the time of paper, large mainframe systems, and the infancy of the web. This guide should help navigate through the web of acronyms and regulations.