|
|
|
|
|
|
by dwheeler
3542 days ago
|
|
|
> Followup question: how do we find independent folk to help us check our work? I don't have a very good answer for proprietary software. If a company is serious, I think they should pay people to independently review it. There's great evidence that software inspections detect a lot of defects, but in many circumstances detecting & fixing defects is simply not valued as much as the costs of reviewers. We need customers to demand independent analysis of important software. For open source software, the situation is often better. I think you should work with the people who write/manage/run the relevant system or language package management tools so that the packages are reproducible. As far as the broader question of "checking our work", there a lot of things you can do to make it easier for people to collaborate. I strongly encourage all OSS projects to try to get a CII best practices badge: https://bestpractices.coreinfrastructure.org/ That has a list of basic things you should do to encourage collaboration and be secure. (Full disclosure: I lead the CII best practices badge project. But you should do it anyway :-) ). |
|
|
The one I'm happiest to exceed is the 60 day CVE-fix window. Our policy is to release updated versions of our buildpacks and rootfs within 48 hours of a high-severity CVE being patched upstream -- usually within the same day, actually. Only possible because we have very extensive testing and build automatic.
For internal reviews and teaching, one idea that one of my colleagues floated was having a red team with engineers rotated through that team. The idea being that it's easiest to think like an attacker if you have, for some time, been an attacker.
It would be difficult to find the right tempo, though. It'd take a few weeks to get a grip on common attack types and then start hunting for flaws, and we'd be struggling to find the balance between rotating as many engineers through as possible vs maintaining ongoing feature work and maintenance.