GitHub | Breaking Cybersecurity News | The Hacker News

There's a war raging in the heart of every developer. On one side, you have the id: the impulse-driven creative force that wants to code at the speed of thought and would prefer to deploy first and ask questions later. On the other side, there's the superego, which wants to test every line of code and would push a release by a month if it meant catching one extra bug.  Experienced developers know how to act as a referee between these two forces and find the right balance between speed and security. But inexperienced or overworked devs often put their id in the driver's seat, which leads (among other things) to accidentally leaking developer secrets. These secrets include things like API and SSH keys, unencrypted credentials, and authentication tokens. Calling developer secrets "the keys to the kingdom" is something of a cliche, but it's tough to think of another phrase that accurately captures the unique power of this data. Unfortunately, the people who most appreciate the pow...

Security has always been a game of risk management, not risk elimination. Every decision to address one threat means potentially leaving another unattended. That deciding of which threat to address – and in what order – is the name of the game. In this triage process, abuse vulnerabilities,  i.e. , exploiting legitimate features of a platform in unintended ways to conduct digital misdeeds such as phishing campaigns, can get pushed down the priority list of security issues. I would like to argue that it's time we stop separating the concept of abuse vulnerabilities and security vulnerabilities.  Unlike security vulnerabilities that are, in essence, exploited loopholes or bugs in the code, fixes for abuse vulnerabilities can be slow to come. Yet these openings for abuse can easily lead to disaster if left unattended. Recent figures show that  68% of breaches  originate from these exact types of exploitations involving the human element making a mistake such as phish...