| ▲ | jmward01 12 hours ago |
| This may not be popular, but is there a place for required human actions or just timed actions to slow down things like this? For instance, maybe a GH action to deploy requires a final human click and to change that to cli has a 3 day cooling period with mandatory security emails sent out. Similarly, you switch to read only for 6 hrs after an email change. There are holes in these ideas but the basic concept is to treat security more like physical security, your goal isn't always to 100% block but instead to slow an attacker for xxx minutes to give the rest of the team time to figure out what is going on. |
|
| ▲ | ArcHound 12 hours ago | parent | next [-] |
| Hi, security here. We've tried, but the amount of people you need for this vs the amount of people you have trying to review and click the big button always means that this step will be a bottleneck. Thus this step will be eliminated. A much better approach would be to pin the versions used and do intentional updates some time after release, say a sprint after. |
| |
| ▲ | zbentley an hour ago | parent | next [-] | | Pinning, escrowing, and trailing all help, but I'm not sure "this step will be eliminated" is inevitable. Package manager ecosystems are highly centralized. npm.org could require MFA (or rate limit, or email verification, or whatever) and most packagers would gripe but go along with this. A minority would look for npm competitors that didn't have this requirement, and another minority would hack/automate MFA and remove the added security, but the majority of folks would benefit from a centralized requirement of this sort. | |
| ▲ | jmward01 12 hours ago | parent | prev | next [-] | | Yeah, I am looking at that on the use end. It sounds like on the python side this type of thing will be more standard (uv now and soon pip supported with version date requirements). I think time is a big missing element in many security in depth decisions. It can be time until you adopt like use no package newer than xx days or time it takes to deploy etc etc. Unfortunately the ecosystem is getting really diverse and that means ever more sophisticated attacks so we may need to do things that are annoying just to survive. | |
| ▲ | themafia 12 hours ago | parent | prev [-] | | Why not just release escrow? If I try to push a new release version another developer or developers have to agree to that release. In larger projects you would expect the release to be coordinated or scheduled anyways. Effectively we're just moving "version pinning" or "version delay" one layer up the release chain. |
|
|
| ▲ | TZubiri 3 hours ago | parent | prev [-] |
| lgtm (didn't read) |
