JFrog introduced Project Pyrsia, an open-source software community initiative that utilizes blockchain technology to secure software packages (A.K.A Binaries) from vulnerabilities and malicious code.
The field of cybersecurity is awash with four-letter acronyms. As if to prove the three letters is not enough (and that security always needs to go one step further), we have SAST, DAST and RASP, SIEM and SOAR. But even cybersecurity professionals must find DevSecOps a bit of a mouthful. DevSecOps inserts security principles and practices into the DevOps lifecycle, squeezing security into the terminology of development and deployment with all the subtlety of a crowbar.
The fact that this needs to happen deserves some exploration, not least because of what it suggests: that DevOps left in the wild, doesn't take cybersecurity into account. So, did the creators of DevOps just fall asleep in that lecture, or is something more fundamental going on? What is the relationship between cybersecurity in general and DevOps, and most importantly, what do organizations need to do about it?
To answer these questions, we can go to the roots of why cybersecurity exists: risk. Or, more accurately, the mitigation of business risk. That is, what might go wrong for an organization, should issues not be addressed and treated.
A harsh, but fair statement is that other risks are less important: customer privacy, for example, only matters because of the potential for reputational damage, compliance failure or loss of revenue, should privacy be breached.
Applications, systems, services, data stores, network devices and end points are all sources of business risk. Thus, we have a raft of well-acronymed solutions to cover the breadth of this threat surface, dealing with the range of security issues out there (as characterized by the 3-acronym confidentiality-integrity-availability).
But what about applications and services still to be built, and how might their very construction also contribute to business risk?
In recent years, businesses have been struggling to keep up with cloud-metric startups — the latter a clear and present source of business risk, as they eat away at incumbent market share. The need to develop new, tech-driven solutions quickly has driven the need for speed, which has pervaded all aspects of software production.
As we have seen in other areas, however, doing things fast has been at the expense of manageability; and equally, has left the door open for cybersecurity risks.
A major element of DevSecOps is, therefore, a literal re-insertion of security back into the software creation pipeline. It may be true that developers don't necessarily get out of bed in the morning thinking about how to build software securely; equally, first versions of some software products may lack even the most obvious security measures, such as two-factor user authentication, or encryption of data in motion, simply because nobody thought about them.
But we can't expect leopards to change their spots, which is why we have best practices and tools to respond to our reasonably standard human traits (to coin another cybersecurity trichord, the answer lies across all elements of people, process, technology).
One piece of good news is that security tools are legion: the security technology space is as dynamic and complex as the challenges it seeks to address (which is why we need all those four-letter acronyms).