You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Not sure if this is the best place to ask, and please feel free to reply directly ([email protected]) if preferred.
I am working on team getting an ATO in place for using GitHub and am wondering how you all have structured your security guidelines to support open development on GitHub. For example, what, if any controls are in place to handle the need to maintain security and administrative reviews on repositories that are public or going to be made public? Do you maintain a prescriptive development workflow to enforce any policy requirements? Do you use some combination of policy and technical solution to ensure that repositories remain free from PII?
Thanks for any information you might be able to provide!
The text was updated successfully, but these errors were encountered:
@jlaura Hello from a year in the future! I figure this info is probably no longer helpful to you, but maybe it'll be helpful to somebody else stumbling on this issue.
I no longer work for 18F/TTS, but I previously worked on a project there. Robust, specific, well-maintained documentation was a big part of our argument for why our Authorizing Officials should allow us to do public open source development. Here are some components:
Configuration management policy, including a specific change workflow - it's a relatively standard pull request workflow, just carefully described.
Sensitive information policy - including a requirement to install an equivalent to git-secrets and specific details about incident response for accidental secret leaks.
cloud.gov AC-22 training (not public, but you could probably get a copy by doing a FOIA request, or maybe by just emailing the team). In addition to the typical contingency plan & incident response trainings required for all members of the team, we developed a custom mandatory training on managing public and private information, covering the policies listed above and encouraging discussion & questions. New members had to receive the training within a certain number of days of joining the team, and everyone had to get it at least annually.
Not sure if this is the best place to ask, and please feel free to reply directly ([email protected]) if preferred.
I am working on team getting an ATO in place for using GitHub and am wondering how you all have structured your security guidelines to support open development on GitHub. For example, what, if any controls are in place to handle the need to maintain security and administrative reviews on repositories that are public or going to be made public? Do you maintain a prescriptive development workflow to enforce any policy requirements? Do you use some combination of policy and technical solution to ensure that repositories remain free from PII?
Thanks for any information you might be able to provide!
The text was updated successfully, but these errors were encountered: