3 ms·

In the end, what gets deployed is the responsibility of the entity doing the deployment. Maybe the organization wants to deploy the latest trunk on every commi

by dsr_ 5y ago

In the end, what gets deployed is the responsibility of the entity doing the deployment. Maybe the organization wants to deploy the latest trunk on every commit. There are probably some situations where that is reasonable. Those situations probably shouldn't involve people's money, privacy or safety. Setting up a two-stage local repository isn't very hard. The intake side gets updates from upstream, and the deployment side gets updates from the intake side when the packages have been reviewed and hopefully tested. Do this for everything with an external upstream -- Ruby gems, Python modules, JS libraries, whatever -- and you have insulated yourself against supply-chain attacks. As a bonus, if your leftpad function just goes missing upstream, you still have a full copy in your deployment repository, and will until you decide it's time to implement your own.

mrweasel 5y ago
> In the end, what gets deployed is the responsibility of the entity doing the deployment. Yes and no, I don't disagree, but remember classic hosting, semi-managed infrastructure still exists. We often get container images delivered and are responsible for the operational side of things, but we have no control of what is actually inside the containers. Sure we can make requests, or inform a customer that we believe what they are doing isn't safe. Ideally we could reject a request to run a container, but in reality that's not really an option. That shifts the responsibility of security more in the direction of the developers and they often do not have regular patch management as a priority.
- dsr_ 5y ago
  If your organization isn't in control of the software you are running, you are a service provider and you have to treat them as potentially hostile external entities. Your responsibility is for the infrastructure, and you must explicitly disclaim responsibility for the functionality and security of anything inside the containers. This is, incidentally, the antithesis of "devops".

by dsr_ 5y ago

mrweasel 5y ago

> In the end, what gets deployed is the responsibility of the entity doing the deployment. Yes and no, I don't disagree, but remember classic hosting, semi-managed infrastructure still exists. We often get container images delivered and are responsible for the operational side of things, but we have no control of what is actually inside the containers. Sure we can make requests, or inform a customer that we believe what they are doing isn't safe. Ideally we could reject a request to run a container, but in reality that's not really an option. That shifts the responsibility of security more in the direction of the developers and they often do not have regular patch management as a priority.

dsr_ 5y ago
If your organization isn't in control of the software you are running, you are a service provider and you have to treat them as potentially hostile external entities. Your responsibility is for the infrastructure, and you must explicitly disclaim responsibility for the functionality and security of anything inside the containers. This is, incidentally, the antithesis of "devops".