71–80 of 129 posts
(yes it is a security issue (as it defeats a security policy) but I hope it remains unfixed because it's a stupid policy)
This is a prime example of "If you make an unusable secure system, the users will turn it into an insecure usable one." If someone is actively subverting a control like this, it probably means that the control has morphed from a guardrail into a log across the tracks. Somewhat in the same vein as AppLocker &co. Almost everyone says you should be using it, but almost no-one does, because it takes a massive amount of e…
Nobody outside of the IT security bubble thinks that using AppLocker is a sensible idea. Companies have no business telling their employees which specific programs they can and cannot run to do their jobs, that's an absurd level of micromanagement.
I'm usually on the side of empowering workers, but I believe sometimes the companies do have business saying this.
One reason is that much of the software industry has become a batpoop-insane slimefest of privacy (IP) invasion, as well as grossly negligent security.
Another reason is that the company may be held liable for license terms of the software.
Another reason is that the company may be held liable for illegal behavior of the software (e.g., if the software violates some IP of another party).
Every piece of software might expose the company to these risks. And maybe disproportionately so, if software is being introduced by the "I'm gettin' it done!" employee, rather than by someone who sees vetting for the risks as part of their job.
https://dlthub.com/docs/walkthroughs/deploy-a-pipeline/deplo...
It's the easiest way for many startups to get people to try out your software for free.
Earlier quoted context omitted.
Nobody outside of the IT security bubble thinks that using AppLocker is a sensible idea. Companies have no business telling their employees which specific programs they can and cannot run to do their jobs, that's an absurd level of micromanagement.
> Companies have no business telling their employees which specific programs they can and cannot run to do their jobs, that's an absurd level of micromanagement. I'm usually on the side of empowering workers, but I believe sometimes the companies do have business saying this. One reason is that much of the software industry has become a batpoop-insane slimefest of privacy (IP) invasion, as well as grossly negligent s…
This is a prime example of "If you make an unusable secure system, the users will turn it into an insecure usable one." If someone is actively subverting a control like this, it probably means that the control has morphed from a guardrail into a log across the tracks. Somewhat in the same vein as AppLocker &co. Almost everyone says you should be using it, but almost no-one does, because it takes a massive amount of e…
Nobody outside of the IT security bubble thinks that using AppLocker is a sensible idea. Companies have no business telling their employees which specific programs they can and cannot run to do their jobs, that's an absurd level of micromanagement.
Earlier quoted context omitted.
> Companies have no business telling their employees which specific programs they can and cannot run to do their jobs, that's an absurd level of micromanagement. I'm usually on the side of empowering workers, but I believe sometimes the companies do have business saying this. One reason is that much of the software industry has become a batpoop-insane slimefest of privacy (IP) invasion, as well as grossly negligent s…
Developers are going to write code to do things for them, such as small utility programs for automating work. Each custom program is a potentially brand new binary, never sent before by the security auditing software. Does every program written by every dev have to be cleared? Is it best in such a system to get an interpreter cleared so I can use that to run whatever scripts I need?
I feel like GitHub's CI/CD offering is too "all-in" now. Once we are at a point where the SCM tool is a superset of AWS circa 2010, we probably need to step back and consider alternatives. A more ideal approach could be to expose a simple rest API or webhook that allows for the repo owner to integrate external tooling that is better suited for the purpose of enforcing status checks. I would much rather write CI/CD to…
Had these exact same thoughts while I was configuring a series of workflows and scripts to get around the multiple unjustified and longstanding restrictions on what things are allowed to happen when. That sinking feeling when you search for how to do something and all of the top results are issues that were opened over a decade ago... It is especially painful trying to use github to do anything useful at all after be…
It used 1.8 days of time to run for a single day? I'm less curious about who's paying for it than who's _using _ it on your repo, because I can't even imagine having an average of almost two people scanning a codebase every single minute of the day.
I don’t understand the risk honestly. Anyone who can write code to the repo can already do anything in GitHub actions. This security measure was never designed to mitigate against a developer doing something malicious. Whether they clone another action into the repo or write custom scripts themselves, I don’t see how GitHub’s measures could protect against that.
The idea is that the organization does not trust these third-parties, therefore they disable their access.
However this solution bypasses those lists by cloning open-source actions directly into the runner. At that point it’s just running code, no different from if the maintainers wrote a complex action themselves.
This is a prime example of "If you make an unusable secure system, the users will turn it into an insecure usable one." If someone is actively subverting a control like this, it probably means that the control has morphed from a guardrail into a log across the tracks. Somewhat in the same vein as AppLocker &co. Almost everyone says you should be using it, but almost no-one does, because it takes a massive amount of e…
Nobody outside of the IT security bubble thinks that using AppLocker is a sensible idea. Companies have no business telling their employees which specific programs they can and cannot run to do their jobs, that's an absurd level of micromanagement.
https://itwire.com/guest-articles/guest-opinion/is-an-oracle...
Security practitioners are big fans of application whitelisting for a reason: Your malware problems pretty much go away if malware cannot execute in the first place.
The Australian Signals Directorate for example has recommended (and more recently, mandated) application whitelisting on government systems for the past 15 years or so, because it would’ve prevented the majority of intrusions they’ve investigated.
https://nsarchive.gwu.edu/sites/default/files/documents/5014...