The Creative Process of Street Skating and What Open Source Folks Can Learn From It

"All skateboarders speak a language of our own devising. We take simple movements and chunk them together in such a way that we form more complex ones." - Rodney Mullen

The ethos of skateboarding is born out of a maverick spirit. It's wrought from verve and a stubborn determination to flow on one's own terms. There's a subtle rebelliousness in carving out tight lines along with hot asphalt, propelled forward by one's own power. Challenged by your physical environment, you go for it, bombing down a hill or grinding out a curb, making the most of exposed surfaces. You skate because you can.

You may also like: Why You Need to Think Differently About Open-Source Security

From Blasé to Badass

I was recently turned on to a TED talk that legendary skateboarder Rodney Mullen gave back in 2014. Considered the "Godfather of Modern Street Skating," Mullen is credited with inventing the flat ground Ollie that revolutionized skateboarding. His ability to manipulate the board, literally launching it up and over objects, helped morph the sport from the sedate motions of freestyle to the gritty contortions that define street skating. All of a sudden, skate-able terrain included seemingly impossible features like stairs and handrails.

About halfway through his lecture, he drew similarities between skaters, hackers, and the open-source community. Say what? He surmises that these communities are similar, each conducive to innovation and collaboration.

And he makes some good supporting points like no one person "owns" a trick. They are shared, learned, modified, and shared again amongst peers. The creative process of developing code or creating a new trick is as much about breaking barriers as it is about raising a proverbial fist and shouting expletives in triumph at the status quo. Writing and committing clean code provides its own rush — a by-product of the creative process.

Rodney shares more insights on his comparison:

"They connect disparate information, and they bring it together in a way that a security analyst doesn't expect. It doesn't make them good people, but it's at the heart of engineering, at the heart of a creative community, an innovative community, and the open-source community, the basic ethos of it is, take what other people do, make it better, give it back so we all rise further."

"...we all rise further." Think about that. He frames his skateboarder/hacker/developer analogy with anecdotes that highlight the altruistic contributions to the process - whether it be engineering or skateboarding - and then seeing the creative take on a life of its own when others embrace it.

The end result is a richer, organic by-product, a version of a vision that found expression and became reality. It's truly a beautiful thing. And yet, like skateboarding, open-source software (OSS) also carries substantial risks and vulnerabilities.

But First, What Exactly Is Open-Source Software?

Generally speaking, it is software that can be freely accessed, changed, used, and shared by anyone. The Open Source Initiative's definition outlines 10 criteria that must be met by any software license to be labeled as such including free redistribution, the integrity of the author's source code, technology neutrality, and no discrimination against persons or groups.

OSS enables organizations to continuously improve and deliver a quality product. Open source is flexible, cost-effective, and fast. Using it can help accelerate development schedules, reduce licensing costs, and better leverage personnel.

Like skating, large user communities share an interest in quickly finding solutions to do something better. In the case of OSS, it's in identifying and fixing vulnerabilities.

Skate at Your Own (Open Source) Risk (Management)

Analysts such as Forrester and Gartner, have noted that over 90 percent of IT organizations use OSS in mission-critical workloads, with open source composing up to 90 percent of new codebases. The risk is not from open source use per se, but from unpatched software.

With proprietary and commercial software, publishers can push patches and updates. With OSS, the onus is on the user to track for vulnerabilities and fixes, contributing to the burden of manually tracking components. And one of the challenges for organizations is keeping up-to-date and accurate inventories of the open-source components used in their applications.

Having an incomplete software inventory leaves DevOps teams essentially "blind" as evidenced by Equifax's massive 2017 data breach wherein a U.S. Senate Permanent Subcommittee on Investigations highlighted Equifax's negligent practices.

The audit report noted that Equifax lacked a comprehensive IT asset inventory, meaning it lacked a complete understanding of the assets it owned. This made it difficult, if not impossible, for Equifax to know if vulnerabilities existed on its networks. If a vulnerability cannot be found, it cannot be patched.

If you can't see, you can't fix it. Makes sense. Luckily, achieving real-time visibility into libraries and components is possible, preventing these types of compromises. You just have to adopt the right software and best practices.

Further Reading

How to Secure Open-Source Software

Why You Need to Think Differently About Open-Source Security

Open-Source Software Security Risks and Best Practices