JDjdorfman·Oct 21, 2017Submission
Best Practices Criteria for FLOSS
1 points · Open discussionossf
best-practices-badge
Ruby2015–2025
ossf / best-practices-badge
best-practices-badge
🏆Open Source Security Foundation (OpenSSF) Best Practices Badge (formerly Core Infrastructure Initiative (CII) Best Practices Badge)
10Distinct people
26Mentions
1Explicit recommenders
1.4KGitHub stars
What to know before exploring
What it is
🏆Open Source Security Foundation (OpenSSF) Best Practices Badge (formerly Core Infrastructure Initiative (CII) Best Practices Badge)
GitHub
Where it is used
No documented product use has been verified yet.
What people are saying
They're talking about a different kind of best practices, but I highly recommend taking a look at the Core Infrastructure Initiative's Best Practices Project [0], which was…
dankohn1 used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 10:02:05 AM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year26 dated mentions
Observed mentions: 2015-10-10 09:04:16 UTC to 2025-05-22 15:23:45 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 3 | 1 | 2 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 7 | 2 | 5 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 8 | 1 | 7 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 1 | 0 | 1 |
What Hacker News says
8 sourceshttps://gemnasium.com/ emails you when a security vulnerability arises. Otherwise, the badge on the readme changes yellow when you're out of date and red when there's a vulnerability. Free for open source.
See https://github.com/coreinfrastructure/best-practices-badge#c... for an example.
In Ask HN: How do you keep track of node packages/ruby gems security issues?I currently push all passing builds on master to master.bestpractices.coreinfrastructure.org, and also run staging and production environments. See https://github.com/coreinfrastructure/best-practices-badge/b...
My question is when switching to a Docker workflow, does it make sense to use the same image for test on CircleCI as for deployment on staging and production.
In Launching Today: CircleCI 2.0 Reaches General AvailabilityI've been experimenting with multi-stage builds, and they do let me build a leaner image with clearer syntax by using one the first image to build my gems, and then copying the gems to the final image. <https://github.com/coreinfrastructure/best-practices-badge/b...
However, that doesn't fix the problem of having lots of development and test gems installed in test that I don't want for production. I don't know of a way of copying just my production gems to a production image.
In Launching Today: CircleCI 2.0 Reaches General AvailabilityDo you recommend using the same Docker image that passes tests on CircleCI in production?
I have an open source Rails app <https://github.com/coreinfrastructure/best-practices-badge> that self-certifies that open source projects are following best practices. It currently uses CircleCI 1.0 and then deploys to Heroku <https://circleci.com/gh/coreinfrastructure/best-practices-ba....
If I configure it for development and test, it will contain all the test and development gems in addition to the production ones <https://github.com/coreinfrastructure/best-practices-badge/b.... I would also need to include gcc and other build tools. But I would have immutability in that my dev, test and production images would be identical.
Or, should I use one image for dev and test, and then build a different image for production, in order to have the smallest
Read the rest
possible size? CircleCI supports building <https://circleci.com/docs/2.0/building-docker-images/> further Docker images, but then there's a chance of losing dev/prod parity if, for example, a software dependency gets updated in the meantime.
Dan: Thanks again for your work (I also work on BadgeApp)!
One other important change due to the Rails 5 upgrade was that because jquery-turbolinks doesn't support Rails 5 [0], we eventually had to drop both jquery-turbolinks and turbolinks. If you're using jquery-turbolinks, you may also need to drop both jquery-turbolinks and turbolinks. Turbolinks doesn't work correctly with many JavaScript libraries (causing no end of subtle bugs), and in our case the performance boost turbolinks is supposed to provide, so turbolinks just wasn't worth the trouble anyway. Good riddance.
Rails 5 has some nice additions. I particularly appreciate that Rails 5 has two new security hardening mechanisms to reduce the risk of CSRF security vulnerabilities: per-form CSRF tokens and origin-checking CSRF mitigation. We use a number of mechanisms to make o
Read the rest
ur application secure [1].
The application doesn't have many LOC, but we do work to keep it that way. We try to reuse code where it makes sense, and always try to keep it simple. Still, it doesn't take many lines to create a useful app, and that's a good thing.
[0] https://github.com/kossnocorp/jquery.turbolinks/issues/56
[1] https://github.com/linuxfoundation/cii-best-practices-badge/...
My holiday project was to upgrade a Rails project I helped create to Rails 5. The BadgeApp [0] is used to certify open source projects as satisfying the Core Infrastructure Initiative's Best Practices Badge. It is open source, so you can see the diff [1] if you're interested. The upgrade took me several hours, and was greatly assisted by our 99% test coverage. Biggest line count change was from needing to explicitly specify params in tests. The biggest annoyance was that Fastly's gem still doesn't support Rails 5, so I needed to fork it [2].
I too am hugely appreciative of the Rails ecosystem.
[0] https://github.com/linuxfoundation/cii-best-practices-badge/
[1] https://github.com/linuxfoundation/cii-best-practices-badge/...
[2] https://github.com/fastly/fastly-rails/pull/67
Here are the app statistics:
+----------------------+--------+-
Read the rest
-------+---------+---------+-----+-------+
| Name | Lines | LOC | Classes | Methods | M/C | LOC/M |
+----------------------+--------+--------+---------+---------+-----+-------+
| Controllers | 687 | 476 | 8 | 59 | 7 | 6 |
| Helpers | 184 | 134 | 0 | 21 | 0 | 4 |
| Models | 711 | 470 | 5 | 55 | 11 | 6 |
| Mailers | 160 | 115 | 3 | 12 | 4 | 7 |
| Javascripts | 405 | 308 | 0 | 35 | 0 | 6 |
| Libraries | 369 | 281 | 0 | 0 | 0 | 0 |
| Tasks | 369 | 281 | 0 | 0 | 0 | 0 |
| Controller tests | 605 | 513 | 6 | 53 | 8 | 7 |
| Helper tests | 56 | 45 | 2 | 7 | 3 | 4 |
| Model tests | 398 | 309 | 9 | 37 | 4 | 6 |
| Mailer tests | 71 | 54 | 4 | 5 | 1 | 8 |
| Integration tests | 614 | 446 | 10 | 25 | 2 | 15 |
+----------------------+--------+--------+---------+---------+-----+-------+
| Total | 4629 | 3432 | 47 | 309 | 6 | 9 |
+----------------------+--------+--------+---------+---------+-----+-------+
This is great to see. For those who don't know, this is an "assurance case" (definition: "a body of evidence organized into an argument demonstrating that some claim about a system holds, i.e., is assured") - https://www.us-cert.gov/bsi/articles/knowledge/assurance-cas...
I'm glad to see more assurance cases. You can't just do one thing and have a secure system. And if you want people to trust you, you need to give them a reason to trust.
The CII best practices badge ( https://bestpractices.coreinfrastructure.org ) also
has an assurance case; details at https://github.com/linuxfoundation/cii-best-practices-badge/... . If you want to help us make that better, let us know!
In Google Infrastructure Security Design Overview