18f / before-you-ship Goto Github PK
View Code? Open in Web Editor NEWmerged into the TTS Handbook
Home Page: https://handbook.tts.gsa.gov/#launching-software
License: Other
merged into the TTS Handbook
Home Page: https://handbook.tts.gsa.gov/#launching-software
License: Other
I'm not sure if this is a misconfiguration in this project, or an issue with the guide-style (https://github.com/18F/guides-style), but css overrides for this guide are not appearing in production.
Locally, I see that my assets/css/styles.scss are merged into the styles:
On the server, I see the raw guide styles used:
Is this a misconfiguration on our part? I see a similar situation with the agile guild's page: https://pages.18f.gov/agile/
Project members should understand the criteria and implications of each.
@NoahKunin I'll need some help from you on this...anything you can point me to that has information already?
Not sure if this warrants its own repo...thoughts?
See Slack convo.
This site (and our ATO process in general) is in as much need of content help as technical help. We have documentation scattered all over the place (see #12 and links from there), without any easy steps for developers or product managers to follow (#29).
It's not clear to people what changes to a project should constitute a "new" ATO being created, though maybe it's irrelevant once we move to continuous authorization? I assume in that case they have a System Security Plan that stays up-to-date throughout the development cycle, and new action only needs to be taken if they change level? @NoahKunin Does that sound right? Any other guidance here?
Raised because of https://github.com/18F/DevOps/issues/542.
/cc @gboone
The page is called before you ship, but it catalogs a lot of tasks that should begin almost as soon as a project itself begins. To emphasize that, would it be helpful if we compiled a 'Working Backwards' task timeline for this information?
The scale & tasks are obviously different, but I find the Startup Weekend Task Timeline (http://organizer.startupweekend.org/) super helpful when organizing events.
https://pages.18f.gov/before-you-ship/security/scanning/#alerts should be expanded to provide more detail about what qualifies an alert as high/medium/low.
Someone coming into this for the first time would presumably care about reading the triggers to then decide if they need to learn about the relevant law or whatever. We should lead with
Will your app be collecting personal information? If so, ...
for example.
https://pages.18f.gov/before-you-ship/security/ has a lot of information that is no longer relevant in the cloud.gov world, or that should be moved to the ATO page(s).
Not sure why it's a PDF in the first place, but having it as Markdown means we can make changes more easily. @NoahKunin Do you have the source file that the PDF was generated from?
/cc @konklone
Would love to incorporate https://github.com/18F/glossary.
from the Introduction (home page of the site)
https://hub.18f.gov/private/standards/security/#
https://pages.18f.gov/before-you-ship/infrastructure/good-production-practices/#monitoring
has some information, but since it's a required control for ATO, we should make sure to include more detailed instructions about how to set up New Relic / Sentry / whatever.
@mogul @LindsayYoung I remember seeing some instructions around this somewhere, but can't remember. Any idea?
Per @jezhumble's Slack post, ATO requests should now move to https://github.com/18F/compliance. Maybe we convert the checklist to an issue template there?
The Client Tags section links to the 18F Enterprise Architecture spreadsheet as the source of project UIDs. That spreadsheet does not contain the ids.
Furthermore, should we be linking to an internal Google Doc on a publicly accessible page?
From @DavidEBest in Slack:
Whoever signs off and accepts the risk of operating an information system if you were to have built this system yourselves needs to sign the delegation letter. This person is normally called the Authorizing Official. They will have received this title through a series of delegations from the head of the [agency], presuming procedures were followed.
Note this document is critical and urgent - it clarifies and stipulates that the [agency] is not the system owner, 18F/GSA is, which allows us to do both what we've done to date and to complete the work we have in front of us. Without it, there is a lack of clarity, potentially legal in nature, on who is the customer and who is the provider of this system which makes it impossible to correctly move the system through the variety of compliance requirements we have in front of us.
I know that it also came up via @wslack with the FOIA project, so would be good to have an explainer about how ATO delegation works.
/cc @leahbannon
What we currently have on the ATO page
An Authority to Operate (ATO) is a complicated security review process that is required before you can deploy anything on the public web. Before a system is made publicly accessible on the Internet, it must go through either the full ATO process or a 90-Day Authority to Test. If either are not yet complete, the system must have some level of authentication required for a user to enter.
has the following issues:
As a developer, I should know what reports are required of me for ATO, and where they should be put.
What reports are needed by @NoahKunin to verify that the application was scanned and where should the developer put them?
Is there a preferred format? HTML/JSON
Should there be an accompanying report describing false positives?
...or at least find a better place for it. As @DavidEBest pointed out in https://github.com/18F/before-you-ship/pull/38/files#r48160659, doesn't really make sense to have it in the AWS page.
Extracted from #81 (comment).
If Nessus is not going to be used going forward, should it be removed from the DevOps checklist?
If it should still be used, its usage should be documented.
From #1 (comment):
- examples of system architecture diagrams that have successfully passed through ATO
- list of things that are FedRamp or already ATO'd. If you pick components that don't have an ATO, the process is longer (like MyUSA using RDS and ElastiCache)
- expected timelines for each step of the process
- when you should start the process (hint: before you finish coding the version you want to release)
- when do you need to amend the ATO? What changes to the product trigger that need?
- what happens at the end of 1 year?
Currently, there are extra spaces in the way we're displaying unrendered markdown for copy and pasting to issues. So if you copy and paste into an issue, you're creating sub-bullets.
This is an issue for the accessibility issue text from the index.md file, but not the ATO one.
Broken out from #65.
When we "finish" a project and hand it off to the agency partner, we need to explain:
Would be nice to have this in checklist form. No strong feelings about whether this information lives in this site or elsewhere.
/cc @leahbannon
Some interesting questions raised in Slack:
Our current exemptions are listed here, but wonder if there's any more we can add there to answer these questions.
/cc @mbland @dlapiduz @NoahKunin @wslack @gboone @dhcole @jeremiak
Can't remember who proposed this idea, but I like it.
The current page is a bit disjointed:
https://pages.18f.gov/before-you-ship/ato/background/
Is this information that project teams need to know?
At the very least, I think it could
https://pages.18f.gov/before-you-ship/infrastructure/aws/
With the move to Cloud Foundry, relatively few developers are given (or need) direct access to AWS.
As brought up by @DavidEBest in:
The reference:
The relationship between what is law vs. regulation vs. guidance in the existing ATO process is murky. How can we clear that up and represent it effectively?
I found a bug and noticed there's a PR from two days ago. We should add something to the CONTRIBUTING.md that sets some guidelines on how to help, like: https://github.com/18F/midas/blob/devel/CONTRIBUTING.md#reviewing-pull-requests
Proposed text:
Except for critical, urgent or very small fixes, leave pull requests open for most of the day or overnight if something comes in late in the day, so that multiple people have the chance to review/comment. Anyone who reviews a pull request should leave a note to let others know that someone has looked at it. For larger edits, we like to have a +1 from someone who has experience with the topic. Please note if you actually can verify the information, such as "sounds right" or "nice clarification" -- a +1 by itself will typically be interpreted as your thinking its a good idea, but not having reviewed in detail.
Anyone on the 18F ???? team who believes the change is good can (and should) merge pull requests that have been reviewed and are older than 1 day. A committer can both review and merge if they are not the author of the pull request.
Currently the ato information is split into two pages, ato
& ato-and-you
. ato
has a top-level link in the nav, but ato-and-you
is not linked from there.
Say that cloud.gov should be used for all projects, unless there's a good reason not to. There should be documentation (somewhere?) about why a different infrastructure setup was used.
/cc @mogul
If the reader has a question about a particular regulation or step, this repo should tell them where/who to go to for more information. This could be some combination of:
One thing I learned at my last job is that it's preferable to have a chat room, mailing list or repository you can go to with questions, rather than an individual, who may be sick or on vacation or no longer working there or whatever.
At the very least, link out to wherever's relevant.
@NoahKunin What was the third one you mentioned?
As referenced in the SSP template.
hi all! There are a number of pages on the Hub that concern Infrastructure guidelines or AWS:
https://hub.18f.gov/aws-access/index.html
https://hub.18f.gov/encrypt-pers-comp/index.html
https://hub.18f.gov/guidelines/index.html
https://hub.18f.gov/cloud-foundry/index.html
I would like to propose that some of this information would be better if it lived here:
https://pages.18f.gov/before-you-ship/infrastructure/aws/
or on the Infrastructure page on the Handbook - https://github.com/18F/handbook/blob/staging/articles/2-about-us/teams/infrastructure.md
Are there objections to moving this content? I want to make sure we account for it as we're completing this migration, and I want to make sure it doesn't overlap with existing content. I would much rather point to this source and the Handbook page for Devops/Infrastructure than to have small islands of content floating around the Hub.
...including what vulnerability scans to run, etc. Maybe it should be a Markdown template of what to paste into an issue on the Devops repo?
https://pages.18f.gov/risk-management-framework/
There is a lot of content here that isn't surfaced in the sidebar. https://github.com/18F/risk-management-framework/tree/18f-pages/pages
Say something like
Is there additional process for your agency, or other edge cases that aren't listed here? Let us know!
...or link to the relevant place.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.