Plaintext
Opensource.com
Getting started
with DevSecOps
The open source guide to DevOps security
OPENSOURCE.COM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ABOUT OPENSOURCE.COM
What is Opensource.com?
OPENSOURCE.COM publishes stories about creating,
adopting, and sharing open source
solutions. Visit Opensource.com to learn more about how the open source
way is improving technologies, education, business, government, health, law,
entertainment, humanitarian efforts, and more.
Submit a story idea: https://opensource.com/story
Email us: open@opensource.com
Chat with us in Freenode IRC: #opensource.com
2 GETTING STARTED WITH DEVSECOPS . CC BY-SA 4.0 . OPENSOURCE.COM
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OPENSOURCE.COM
INTRODUCTION
What is DevSecOps? 4
CHAPTERS
Talking to normal people about security 6
Who will push back the most on a move to DevOps? 8
3 security tips for software developers 10
5 ways DevSecOps changes security 12
GET INVOLVED | ADDITIONAL RESOURCES
Get involved | Additional Resources 14
Write for Us | Keep in Touch 15
GETTING STARTED WITH DEVSECOPS . CC BY-SA 4.0 . OPENSOURCE.COM 3
INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
What is DevSecOps?
BY BRETT HUNOLDT AND AARON RINEHART
The journey to DevSecOps begins with empowerment, enablement,
and education. Here's how to get started.
DEVSECOPS as a practice or an art form is an
evolution on the concept of DevOps.
To better understand DevSecOps, you should first have an un-
bypass or work around security to meet their objectives. At
some firms, the silo creates an expectation that security is
entirely the responsibility of the security team and it is up to
derstanding of what DevOps means. them to figure out what security defects or issues may be
DevOps was born from merging the practices of develop- introduced as a result of a product.
ment and operations, removing the silos, aligning the focus, DevSecOps looks at merging the security discipline within
and improving efficiency and performance of both the teams DevOps. By enhancing or building security into the de-
and the product. A new syner- veloper and/or operational
gy was formed, with DevOps role, or including a secu-
focused on building products rity role within the product
and services that are easy to engineering team, security
maintain and that automate naturally finds itself in the
typical operations functions. product by design.
Security is a common silo This allows companies to
in many organizations. Se- release new products and
curity’s core focus is pro- updates more quickly and
tecting the organization, and with full confidence that se-
sometimes this means cre- curity is embedded into the
ating barriers or policies that product.
slow down the execution of
new services or products to ensure that everything is well Where does rugged software fit into DevSecOps?
understood and done safely and that nothing introduces Building rugged software is more an aspect of the DevOps
unnecessary risk to the organization. culture than a distinct practice, and it complements and en-
Because of the distinct nature of the security silo and the fric- hances a DevSecOps practice. Think of a rugged product
tion it can introduce, development and operations sometimes as something that has been battle-hardened through experi-
mentation or experience.
It’s important to note that rugged software is not necessar-
“DevSecOps enables organizations ily 100% secure (although it may have been at some point in
time). However, it has been designed to handle most of what
to deliver inherently secure is thrown at it.
software at DevOps speed.” The key tenets of a rugged software practice are foster-
ing competition, experimentation, controlled failure, and
-Stefan Streichsbier cooperation.
4 GETTING STARTED WITH DEVSECOPS . CC BY-SA 4.0 . OPENSOURCE.COM
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . INTRODUCTION
How do you get started in DevSecOps? is about making this knowledge highly accessible through
Gettings started with DevSecOps involves shifting security multiple channels and mediums (which are enabled through
requirements and execution to the earliest possible stage in tools) so that it can be consumed and shared in whatever
the development process. It ultimately creates a shift in cul- way teams or individuals prefer. One medium might work
ture where security becomes everyone’s responsibility, not best when team members are coding and another when
only the security team’s.
You may have heard teams talking about a "shift left." If
you flatten the development pipeline into a horizontal line to
include the key stages of the product evolution—from initi-
Finally, and perhaps most
ation to design, building, testing, and finally to operating— importantly, DevSecOps is about
the goal of a security is to be involved as early as possible.
This allows the risks to be better evaluated, socialized, and
training and awareness building.
mitigated by design. The "shift-left" mentality is about mov-
ing this engagement far left in this pipeline. they are on the road. Make the tools accessible and simple
This journey begins with three key elements: and let the team play with them.
• empowerment Different DevSecOp teams will have different preferences,
• enablement so allow them to be independent whenever possible. This is
• education a delicate balancing exercise because you do want econo-
Empowerment, in my view, is about releasing control and mies of scale and the ability to share among products. Col-
allowing teams to make independent decisions without fear laboration and involvement in the selection and renewal of
of failure or repercussion (within reason). The only caveat in these tools will help lower the barriers of adoption.
this process is that information is critical to making informed Finally, and perhaps most importantly, DevSecOps is
decisions (more on that below). about training and awareness building. Meetups, social
To achieve empowerment, business and executive sup- gatherings, or formal presentations within the organiza-
port (which can be created through internal sales, presen- tion are great ways for peers to teach and share their
tations, and establishing metrics to show the return on this learnings. Sometimes these highlight shared challenges,
investment) is critical to break down the historic barriers concerns, or risks others may not have considered. Shar-
and siloed teams. Integrating security into the develop- ing and teaching are also effective ways to learn and to
ment and operations teams and increasing both commu- mentor teams.
nication and transparency can help you begin the journey In my experience, each organization's culture is unique,
to DevSecOps. so you can’t take a “one-size-fits-all” approach. Reach out
This integration and mobilization allows teams to focus to your teams and find out what tools they want to use.
on a single outcome: Building a product for which they Test different forums and gatherings and see what works
share responsibility and collaborate on development and best for your culture. Seek feedback and ask the teams
security in a reliable way. This will take you most of the what is working, what they like, and why. Adapt and learn,
way towards empowerment. It places the shared respon- be positive, and never stop trying, and you’ll almost al-
sibility for the product with the teams building it and en- ways succeed.
sures that any part of the product can be taken apart and
maintain its security. Authors
Enablement involves placing the right tools and resourc- Brett Hunoldt – Technologist, Security and Privacy Advocate,
es in the hands of the teams. It’s about creating a culture Parent, Gamer & Explorer.
of knowledge-sharing through forums, wikis, and informal Aaron Rinehart – DevSecOps, Security+Chaos Engineer-
gatherings. ing=ChaoSlingr, Entrepreneur, RuggedSoftware, Innovation
Creating a culture that focuses on automation and the Catalyst @UnitedHealthGrp.
concept that repetitive tasks should be coded will like-
Adapted from “What is DevSecOps” on Opensource.com, published under a
ly reduce operational overhead and strengthen security. Creative Commons Attribution Share-Alike 4.0 International License at https://
This scenario is about more than providing knowledge; it opensource.com/article/19/1/what-devsecops.
GETTING STARTED WITH DEVSECOPS . CC BY-SA 4.0 . OPENSOURCE.COM 5
TALKING TO NORMAL PEOPLE ABOUT SECURITY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Talking to normal people
about security
BY MIKE BURSELL
Normal people generally just want things to work.
MOST PEOPLE don’t realise quite how much points of view that we’re not going to get fixed until security
1
fun security is, or exactly how is the very top requirement for any project from its inception
sexy security expertise makes you to other people.2 We know to its ending.4
that it’s engrossing, engaging, and cool, they don’t. For this Now, normal people aren’t stupid.5 They know that things
reason, when security people go to the other people (let’s can’t always work perfectly; but they would like them to work
just call them “normal people” for the purposes of this arti- as well as they can. This is the gap7 that we need to cross.
cle), and tell them that they’re doing something wrong, and I’ve talked about managed degradation as a concept [1]
that they can’t launch their product, or deploy their applica- before, and this is part of the story. One of the things that
tion, or that they must stop taking sales orders immediately we security people should be ready to do is explain that
and probably for the next couple of days until this is fixed, there are risks to be mitigated.
then those normal people don’t always react with the levels For security people, those risks should be mitigated by
of gratefulness that we feel is appropriate. “failing closed.” It’s easy to stop risk: you just stop system
Sometimes, in fact, they will exhibit negative respons- operation, and there’s no risk it can be misused. But for
es—even quite personal negative responses—to these many people, there are other risks: an example being that
suggestions. the organisation may in fact
The problem is this: go completely out of busi-
security folks know how ness because some _____8
things should be, and that’s security person turned the
secure. They’ve taken the ordering system off. If they’d
training, they’ve attended offered me the choice to bal-
the sessions, they’ve read ance the risk of stopping tak-
the articles, they’ve skimmed ing orders against the risk of
the heavy books,3 and all losing some internal compa-
of these sources are quite ny data, would I have taken
clear: everything must be it? Well yes, I might have.
secure. And secure gener- But if I’m not offered the
ally means “closed”—partic- option, and the risk isn’t ex-
ularly if the security folks weren’t sufficiently involved in the plained, then I have no choice. These are the sorts of words
design, implementation, and operations processes. Nor- that I’d like to hear if I’m running a business.
mal people, on the other hand, generally just want things It’s not just this type of risk, though. Coming to a project
to work. There’s a fundamental disjoint between those two meeting two weeks before launch and announcing that the
6 GETTING STARTED WITH DEVSECOPS . CC BY-SA 4.0 . OPENSOURCE.COM
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TALKING TO NORMAL PEOPLE ABOUT SECURITY
project can’t be deployed “because the calls against this API 5. While we’ve all met our fair share of stupid normal people,
aren’t being authenticated” is no good at all. To anybody. I’m betting you’ve met your fair share of stupid security
As a developer, though, I have a different vocabulary—and people, too, so it balances out.6
different concerns—to those of the business owner. How 6. Probably more than balances out. Let’s leave it there.
about instead of saying, “you need to use authentication 7. Chasm.
on this API or you can’t proceed,” the security person asks, 8. Insert your favourite adjectival expletive here.
“what would happen if data that was provided on this API 9. Figuratively: I don’t condone bringing any weapons,
was incorrect, or provided by someone who wanted to dis- including firearms, to your place of work.
rupt system operation?” In my experience, most developers
are interested—are invested—in the correct operation of the Links
system they’re running and the data it processes. Asking [1] https://aliceevebob.com/2017/04/25/service-degradation-
questions that show the possible impact of lack of security is actually-a-good-thing/
much more likely to garner positive reactions than an initial [2] https://opensource.com/article/17/11/politics-linux-desktop
“discussion” that basically amounts to a “no.” [3] https://aliceevebob.com/
Don’t get me wrong; there are times when we, as security
people, need to be firm and stick to our guns.9 But in the Author
end, it’s the owners—of systems, or organisations, or busi- I’ve been in and around Open Source since around 1997,
ness units, or resources—who get to make the final decision. and have been running (GNU) Linux as my main desktop at
It’s our job to talk to them in words they can understand and home and work since then: not always easy... [2] I’m a secu-
ensure that they are as well informed as we can possibly rity bod and architect, and am currently employed as Chief
make them. Without just saying “no.” Security Architect for Red Hat. I have a blog – “Alice, Eve &
Bob” [3] – where I write (sometimes rather parenthetically)
Footnotes about security. I live in the UK and like single malts.
1. By which I mean “those poor unfortunate souls who don’t
This article originally appeared on Alice, Eve, and Bob – a security blog and is
read these posts, unlike you, dear and intelligent reader.”
republished with permission. [3]
2. My wife, sadly, seems to fall into this category.
Adapted from “Talking to normal people about security” on Opensource.com,
3. Which usually have a picture of a lock on the cover. published under a Creative Commons Attribution Share-Alike 4.0 International
4. And good luck with that. License at https://opensource.com/article/18/2/talking-about-security.
GETTING STARTED WITH DEVSECOPS . CC BY-SA 4.0 . OPENSOURCE.COM 7
WHO WILL PUSH BACK THE MOST ON A MOVE TO DEVOPS? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Who will push back the most
on a move to DevOps?
BY MIKE BURSELL
DevOps will definitely bring change to your organization, and not everyone
likes change. Here’s how to manage those who fight the inevitable.
YOU’RE MOVING to a DevOps [1] mod-
el for all or part of your
organisation: well done! Somebody, somewhere has made
realisation that things could be more efficient, or faster, or
more secure.
One of the defining points about this type of person or role
the leap. Let’s assume, for the sake of this article, that you is that it often exhibits as a team concern. Teams become
have management buy-in: whatever hurdles needed to be used to a particular way of doing things and settle into roles
jumped, whatever mountains needed to be climbed to get and routines that work for them. What you’re suggesting is
that momentous “Yes.” You’ve got tooling agreed, you’ve upsetting that team and making people do different things.
worked out your processes, You should consider how to
and now all you need to do make the most of the team
is convince people to get as it exists now, maybe even
involved. Should be easy, transitioning members of
right? If only. that team together or making
It turns out that not all peo- a point of celebrating their
ple are as enlightened as successes, rather than sug-
you, the reader of this article. gesting change is needed
Not everybody likes change, because they have in some
and if there’s one thing way failed.
you can be sure of, it’s that
DevOps will bring change to My domain: Fear of
your organisation—how you loss of control
work, what you do, how you interact with other people within As a security person by background, this is one I’m very
the team and beyond. aware of at a personal level. People who have gained a high
I’m going to describe five types of people or roles who may level of expertise in a particular area or domain often feel
push against a move to DevOps, along with a few thoughts threatened when asked to change how they work or apply
about possible tactics to help move them along. We should their knowledge. They will often feel they are being asked
remember, however, that you may not be able to move ev- to give up control and “water down” their expertise in a new
erybody along, and that there may be good reasons why world where “everybody is the expert.”
people don’t want to change what they do, including the fact What’s important to stress in this context is that, rather
that what they do at the moment may work pretty well, both than diluting their expertise, this is an opportunity to apply it
for them and for the organisation. across a broader set of processes. Testing experts need to
explain to developers and operations folks, for instance, how
Not invented here: Fear of the unknown testing methodologies can be exposed in their realms. Typ-
“We’ve done it this way for the past [1/2/5/10/25] years, and ically, exposing experts to a wider audience will be seen by
it’s worked till now.” We’ve all heard this. It may be true, them as a positive and, although there will always be “ivory
or it may not, but if your management has decided that a tower” type personalities who struggle to interact in a more
move to DevOps should be undertaken, even if the exist- team setting, using them in ways where they take on a “con-
ing practices have been working, there’s probably been a sulting” type role may offer positive opportunities.
8 GETTING STARTED WITH DEVSECOPS . CC BY-SA 4.0 . OPENSOURCE.COM
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . WHO WILL PUSH BACK THE MOST ON A MOVE TO DEVOPS?
Stuck in my way: Fear of the new may have very carefully described job roles that make it diffi-
While very similar to “Not invented here,” this is more of an cult to introduce ways of working where they are expected to
individual than a group trait. Knowing what your tasks will be take a more generalist role and learn new skills—both char-
on a day-to-day basis may feel stultifying to some but can be acteristics of DevOps.
very comforting to many, which is why they may not want to The good news is that DevOps can provide more control
move to a world that seems much more “freeform” and un- to members of the team, in many different ways, somewhat
structured. Not everybody can become the sort of generalist reducing the control exercised by the management function.
who thrives on understanding all the different parts of the Explaining this and ensuring that appropriate checks are put
DevOps cycle. in place to safeguard jobs will be key tasks in convincing
The good news is you will still need people who are unions and their members that this is a good change for
ready to settle down on specific tasks and complete them them. The other thing that should happen, of course, is that
in particular ways. In fact, though there may be initial con- management should have included them early on in the pro-
cerns about moving to a different way of working, explain- cess to make sure there has been buy-in from the beginning,
ing that team members will have a fair amount of control rather than a decision “sprung” on them at the last moment.
over exactly how they perform particular tasks may be a
positive message when trying to help this sort of individu- Some final thoughts
al. Hopefully, you will be including training—whether formal As we progress to a bright new future, it is worth bearing in
or informal—as part of your transformation to DevOps, mind that a general good for all does not always translate
and the chance to learn new skills (thereby increasing in- into a positive change for every individual. It is hard to argue
dividuals’ mobility and career prospects) may also act as that the construction of sewerage systems is anything other
an incentive. than a general good, but it hits those whose only job has ever
been collecting the waste from the streets. Hopefully you don’t
People managers: Fear of losing power see your move to DevOps as the construction of a new set of
In many organisations, particularly those with a strongly sewers for your organisation, but be aware of those for whom
developed hierarchy, managers have a great deal of con- change can be difficult and disruptive. There can be a human
trol over how their staff are deployed, what their tasks will cost to even the most well-intentioned development.
be, and how their career progression is managed. All of For me, the most important point to remember is that
these can be directly at odds with a more open DevOps when people get defensive—and occasionally aggres-
approach. For managers who have built their own little sive—it is generally because they feel threatened, and in all
empire, controlling their reports and subreports like pawns these cases we’ve examined, change can be threatening.
around a chess board, a move to DevOps will be chal- These people are your colleagues, they are people, too,
lenging. For managers who are keen to grow members and they should be treated with respect and consideration
of their teams into more expert employees, who measure as people, not just as roles or obstacles to be overcome.
their success on how many other teams ask for their re- In some cases, preserving the status quo in particular parts
ports to be seconded to their teams, and who enjoy seeing of your organisation may be the safest approach—for now,
new skills and career progressions taking place, DevOps at least.
should be an exciting opportunity.
Part of any fix to the problem of resistant people managers Links
is likely to be for executive management to offer both a car- [1] https://opensource.com/resources/devops
rot and a stick. The carrot can include changing how people [2] https://opensource.com/article/17/11/politics-linux-desktop
managers are rewarded into a mechanism that embraces [3] https://aliceevebob.com/
these new behaviours, while the stick may involve removing
team members from those who are obstructive or changing Author
those managers’ role definitions. I’ve been in and around Open Source since around 1997,
and have been running (GNU) Linux as my main desktop at
Unions: Fear of lack of certainty home and work since then: not always easy... [2] I’m a se-
In certain industries and geographies, there are strong curity bod and architect, and am currently employed as Chief
unions. A core mission of unions is to protect workers from Security Architect for Red Hat. I have a blog – “Alice, Eve
exploitation by management who may try to impose changes & Bob” [3] – where I write (sometimes rather parenthetically)
on workers that will not benefit them. Unions are by default about security. I live in the UK and like single malts.
(and understandably) suspicious of changes introduced by
management, so any move to DevOps that has been “bless- Adapted from “Who will push back the most on a move to DevOps?” on
Opensource.com, published under a Creative Commons Attribution Share-
ed” by management may raise concerns and resistance from Alike 4.0 International License at https://opensource.com/article/18/9/
unions and members of unions. In some cases, employees devops-pushback.
GETTING STARTED WITH DEVSECOPS . CC BY-SA 4.0 . OPENSOURCE.COM 9
3 SECURITY TIPS FOR SOFTWARE DEVELOPERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3 security tips for
software developers
BY PETE SAVAGE
Don’t make these common security mistakes that leave you vulnerable to attack.
EVERY DEVELOPER knows the impor-
tance of following
best security practices. But too often we cut corners, maybe
it rest. I tried logging in again, except this time I purposely
entered my password wrong. I didn’t change all of it, just a
single character.
because we have to work hard until those security practic- What I expected to see was a completely different random
es sink in. Unfortunately, that usually takes something like string representing the password. Instead, only the first two
seeing a security malpractice that’s so bad it gets marked in bytes changed. This was interesting. Even though I was rel-
indelible ink in our brains. atively inexperienced, I knew that if the representation of my
I’ve seen a lot of instances of poor security practices password were hashed, as it should have been, it would be
during my career as a sysadmin, but the three I’m going to entirely different, not just two characters different. Heck, even
describe here are basic things that every software developer a GOOD encryption scheme would do that. This, however,
should avoid. It’s important to note that I’ve seen every single was not doing that at all. I tried two more wrong passwords.
one of these errors committed by large companies and expe- Armed with some sheets of paper and a pencil, I spent
rienced developers, so you the next two hours figuring
can’t chalk these mistakes out the decryption scheme.
up to novice junior engineers. At the end of those two
hours, I had a Python script
1. Don’t encrypt that could take any of those
passwords, hash them. “encrypted” passwords and
Earlier in my career, I decrypt it to reveal the orig-
worked for a company that inal password, something
used a management sys- that no one should ever be
tem that held some pretty able to do. I’m sure the per-
important information. One son who dreamed up this
day I was asked to perform encryption scheme never
a security review of the net- thought that someone with
work and the software that stored our critical information. a couple of hours on their hands would ever sit down and
I spent a few minutes poking around before deciding to work it out, but I did.
fire up Wireshark to see what traffic was running around Why? Because I could.
the network. If you have to store passwords for comparison, never en-
I used my local workstation, logged into the information crypt them, as there is always the possibility that someone
system, and noticed something weird. Even though this can find a decryption algorithm or key. A hash has no direct
was before SSL was all the rage, I did not expect to see reverse, meaning no one can reverse it unless they already
data in plain text containing bytes such as “username” and have a table with the mapping from plain text to hash (or they
“password.” Upon closer inspection, it appeared that the simply guess it). Knowing the hash mechanism doesn’t be-
system was sending my username and a random string— tray the integrity of the data, whereas knowing the encryption
that was not my password—across the wire. I couldn’t let scheme and keys will.
10 GETTING STARTED WITH DEVSECOPS . CC BY-SA 4.0 . OPENSOURCE.COM
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 SECURITY TIPS FOR SOFTWARE DEVELOPERS
2. Don’t put secret backdoors in software. particular application, I told my manager that we would need
As part of a third-party software rollout, I was supporting an in-depth security review of the code. I was asked to look
some users who told me that their logins didn’t work. This anyway to see what I could find. I started playing with the
was a paid-for service provided by a vendor, but before trou- app, logged in, and viewed some of the data. Then I found
bling with what is usually one of the most annoying support something really interesting.
calls (“My login doesn’t work”), I thought I would try it myself. If I bookmarked one of the URLs that I hit further into the
It was true, the logins didn’t work. system, I could just copy and paste it into another browser,
The system was a web-based learning management and boom! I’d be there, without having to log in. I asked the
platform, of which we had paid for a small portion of its developer, “Why don’t you check the login on every page?
greater capabilities. As I poked around on the login page If I just enter the URL of a page further into the system, I
a little more, something caught my eye. One character in can get there without logging in.” He asked, “Why would
one of the words looked different. Perhaps it was a different you do that?”
font, a slightly different shaped “o.” Me being me, I viewed “Because I can,” I replied.
the page in source view, and noticed that there was a link
associated with this particular letter. The link was purpose- Don’t leave anything up to chance
fully hidden. The mouse cursor didn’t change on hovering Even seasoned developers can make these mistakes. They
over it. think that someone won’t ever try to delve deeper into a sys-
I gingerly loaded that mystery link into a new browser win- tem that they have no real access to. The problem is people
dow. All of a sudden, I was met with a screen detailing an en- will prod, they will poke. The overriding advice I, someone
tire suite of computers, giving me full control over what they who only dabbles in security, want to impart here is: Don’t
could do and the ability to shut them down, reboot them, take leave anything up to chance. There are people out there like
screenshots, you name it. I telephoned the software vendor me, who like to dig into things and see why and how they
and asked to speak to the IT guy. After jumping through a work. But there are also a great many people who will dig to
few hoops, I finally got to someone who knew what I was exploit your flaws and vulnerabilities.
talking about. Why? Because they can!
“Oh yeah!” he said. “We put that there for easy access, and
no one ever found it until you. We’ll remove it right away.” Be- Author
fore we ended the call, he asked me one final question: “Why Peter is a passionate open source enthusiast who has been
did you start digging around in the HTML?” promoting and using open source products for the last 10
My answer was simple: “Because I could.” years. He has volunteered in many different areas, starting in
It’s just not worth the risk of putting some fancy backdoor the Ubuntu community, before moving off into the realms of
access into any system, because you can bet your bottom audio production and later into writing. Career wise he spent
dollar someone will find it. No matter how obscure, code much of his early years managing and building datacenters
analysis—and just general prodding and poking—often as a sysadmin, before ending up working for Red Hat as a
yields the most surprising and interesting results. Principal Quailty Engineer for the CloudForms product. He
occasionally pops out a book, loves photography, occasion-
3. Authenticate users on every page—not only ally cooks, and lives in the UK with his wife and two children.
on the login page.
At one point in my career, I was involved with a software Adapted from “3 security tips for software developers” on Opensource.
com, published under a Creative Commons Attribution Share-Alike 4.0
development project that was being implemented by a sea- International License at https://opensource.com/article/17/6/3-security-
soned developer. Feeling a little out of my league with this musts-software-developers.
GETTING STARTED WITH DEVSECOPS . CC BY-SA 4.0 . OPENSOURCE.COM 11
5 WAYS DEVSECOPS CHANGES SECURITY. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5 ways DevSecOps
changes security
BY GORDON HAFF
Security must evolve to keep up with the way today’s apps are written and deployed.
THERE’S BEEN AN ongoing kerfuffle over
whether we need to
expand DevOps [1] to explicitly bring in security. After all, the
current era, which brings in not only DevSecOps but new
application architectural patterns, development practices,
and an increasing number of threats, defines a stark new
thinking goes, DevOps [2] has always been something of a normal that requires a faster pace of change. It’s not so
shorthand for a broad set of new practices, using new tools much that DevSecOps in isolation changes security, but
(often open source) and built on more collaborative cultures. that infosec circa 2018 requires new approaches.
Why not DevBizOps [3] for Consider these five areas.
better aligning with business
needs? Or DevChatOps to Automation
emphasize better and faster Lots of automation is a hall-
communications? mark of DevOps generally.
However, as John Wil- It’s partly about speed. If
lis wrote earlier this year [4] you’re going to move fast
on his coming around to the (and not break things), you
DevSecOps [5] terminology, need to have repeatable
“Hopefully, someday we will processes that execute with-
have a world where we no out a lot of human interven-
longer have to use the word tion. Indeed, automation is
DevSecOps and security will one of the best entry points
be an inherent part of all service delivery discussions. Until for DevOps, even in organizations that are still mostly work-
that day, and at this point, my general conclusion is that it’s ing on monolithic legacy apps. Automating routine process-
just three new characters. More importantly, the name really es associated with configurations or testing with easy-to-use
differentiates the problem statement in a world where we as tools such as Ansible [7] is a common quick hit for starting
an industry are not doing a great job on information security.” down the path to DevOps.
So why aren’t we doing a great job on information se- DevSecOps is no different. Security today is a continuous
curity, [6] and what does it mean to do a great job in a process rather than a discrete checkpoint in the application
DevSecOps context? lifecycle, or even a weekly or monthly check. When vulnera-
We’ve arguably never done a great job of information se- bilities are found and fixes issued by a vendor, it’s important
curity in spite of (or maybe because of) the vast industry of they be applied quickly given that exploits taking advantage
complex point products addressing narrow problems. But we of those vulnerabilities will be out soon.
also arguably did a good enough job during the era when
defending against threats focused on securing the perime- “Shift left”
ter, network connections were limited, and most users were Traditional security is often viewed as a gatekeeper at the
employees using company-provided devices. end of the development process. Check all the boxes and
Those circumstances haven’t accurately described most your app goes into production. Otherwise, try again. Security
organizations’ reality for a number of years now. But the teams have a reputation for saying no a lot.
12 GETTING STARTED WITH DEVSECOPS . CC BY-SA 4.0 . OPENSOURCE.COM
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 WAYS DEVSECOPS CHANGES SECURITY
Therefore, the thinking goes, why not move security ear- small and loosely coupled components that can be updated
lier (left in a typical left-to-right drawing of a development and reused without potentially forcing changes elsewhere in
pipeline)? Security may still say no, but the consequences the app. In their purest form, these components can be mi-
of rework in early-stage development are a lot less than they croservices [9] or functions, but the general principles apply
are when the app is complete and ready to ship. wherever you have loosely coupled services communicating
I don’t like the “shift left” term, though. It implies that over a network.
security is still a one-time event that’s just been moved This pattern does introduce some new security chal-
earlier. Security needs to be a largely automated process lenges. The interactions between components can be
everywhere in the application lifecycle, from the supply complex and the total attack surface can be larger be-
chain to the development and test process all the way cause there are now more entry points to the application
through deployment. across the network.
On the other hand, this type of architecture also means
Manage dependencies that automated security and monitoring also has more
One of the big changes we see with modern app devel- granular visibility into the application components be-
opment is that you often don’t write most of the code. Us- cause they’re no longer buried deep within a monolithic
ing open source libraries and frameworks is one obvious application.
case in point. But you may also just use external services Don’t get too wrapped up in the DevSecOps term, but
from public cloud providers or other sources. In many take it as a reminder that security is evolving because the
cases, this external code and services will dwarf what you way that we write and deploy applications is evolving.
write yourself.
As a result, DevSecOps needs to include a serious fo- Links
cus on your software supply chain [8]. Are you getting your [1] https://opensource.com/resources/devops
software from trusted sources? Is it up to date? Is it inte- [2] https://opensource.com/tags/devops
grated into the security processes that you use for your [3] https://opensource.com/article/18/5/steps-apply-devops-
own code? What policies do you have in place for which culture-beyond-it
code and APIs you can use? Is commercial support avail- [4] https://www.devsecopsdays.com/articles/its-just-a-name
able for the components that you are using for your own [5] https://opensource.com/article/18/4/devsecops
production code? [6] https://opensource.com/article/18/6/where-cycle-security-
No set of answers are going to be appropriate in all cas- devops
es. They may be different for a proof-of-concept versus an [7] https://opensource.com/tags/ansible
at-scale production workload. But, as has been the case in [8] https://opensource.com/article/17/1/be-open-source-
manufacturing for a long time (and DevSecOps has many supply-chain
analogs in how manufacturing has evolved), the integrity of [9] https://opensource.com/tags/microservices
the supply chain is critical.
Visibility Author
I’ve talked a lot about the need for automation through- Gordon Haff is Red Hat technology evangelist, is a frequent
out all the stages of the application lifecycle. That makes and highly acclaimed speaker at customer and industry
the assumption that we can see what’s going on in each of events, and helps develop strategy across Red Hat’s full port-
those stages. folio of cloud solutions. He is the co-author of Pots and Vats
Effective DevSecOps requires effective instrumentation to Computers and Apps: How Software Learned to Pack-
so that automation knows what to do. This instrumentation age Itself in addition to numerous other publications. Prior
falls into a number of categories. There are long-term and to Red Hat, Gordon wrote hundreds of research notes, was
high-level metrics that help tell us if the overall DevSecOps frequently quoted in publications like The New York Times
process is working well. There are critical alerts that require on a wide range of IT topics, and advised clients on prod-
immediate human intervention (the security scanning sys- uct and marketing strategies. Earlier in his career, he was
tem is down!). There are alerts, such as for a failed scan, responsible for bringing a wide range of computer systems,
that require remediation. And there are logs of the many pa- from minicomputers to large UNIX servers, to market while
rameters we capture for later analysis (what’s changing over at Data General. Gordon has engineering degrees from MIT
time? What caused that failure?). and Dartmouth and an MBA from Cornell’s Johnson School.
Follow me at @ghaff
Services vs. monoliths
Adapted from “5 ways DevSecOps changes security” on Opensource.com,
While DevSecOps practices can be applied across many published under a Creative Commons Attribution Share-Alike 4.0 International
types of application architectures, they’re most effective with License at https://opensource.com/article/18/9/devsecops-changes-security.
GETTING STARTED WITH DEVSECOPS . CC BY-SA 4.0 . OPENSOURCE.COM 13
GET INVOLVED | ADDITIONAL RESOURCES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
GET INVOLVED
If you find these articles useful, get involved! Your feedback helps improve the status
quo for all things DevOps.
Contribute to the Opensource.com DevOps resource collection, and join the team of
DevOps practitioners and enthusiasts who want to share the open source stories
happening in the world of IT.
The Open Source DevOps team is looking for writers, curators, and others who can help
us explore the intersection of open source and DevOps. We’re especially interested in
stories on the following topics:
• D
evOps practical how to’s
• D
evOps and open source
• D
evOps and talent
• D
evOps and culture
• D
evSecOps/rugged software
Learn more about the Opensource.com DevOps team: https://opensource.com/devops-team
ADDITIONAL RESOURCES
The open source guide to DevOps monitoring tools
This free download for sysadmin observability tools includes analysis of open source
monitoring, log aggregation, alerting/visualizations, and distributed tracing tools.
Download it now: The open source guide to DevOps monitoring tools
The ultimate DevOps hiring guide
This free download provides advice, tactics, and information about the state of DevOps
hiring for both job seekers and hiring managers.
Download it now: The ultimate DevOps hiring guide
The Open Organization Guide to IT Culture Change
In The Open Organization Guide to IT Culture Change, more than 25 contributors from
open communities, companies, and projects offer hard-won lessons and practical ad-
vice on how to create an open IT department that can deliver better, faster results and
unparalleled business value.
Download it now: The Open Organization Guide to IT Culture Change
14 GETTING STARTED WITH DEVSECOPS . CC BY-SA 4.0 . OPENSOURCE.COM
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . WRITE FOR US
WRITE FOR US
Would you like to write for Opensource.com? Our editorial calendar includes upcoming themes,
community columns, and topic suggestions: https://opensource.com/calendar
Learn more about writing for Opensource.com at: https://opensource.com/writers
We're always looking for open source-related articles on the following topics:
Big data: Open source big data tools, stories, communities, and news.
Command-line tips: Tricks and tips for the Linux command-line.
Containers and Kubernetes: Getting started with containers, best practices,
security, news, projects, and case studies.
Education: Open source projects, tools, solutions, and resources for educators,
students, and the classroom.
Geek culture: Open source-related geek culture stories.
Hardware: Open source hardware projects, maker culture, new products, howtos,
and tutorials.
Machine learning and AI: Open source tools, programs, projects and howtos for
machine learning and artificial intelligence.
Programming: Share your favorite scripts, tips for getting started, tricks for
developers, tutorials, and tell us about your favorite programming languages and
communities.
Security: Tips and tricks for securing your systems, best practices, checklists,
tutorials and tools, case studies, and security-related project updates.
Keep in touch!
Sign up to receive roundups of our best articles,
giveaway alerts, and community announcements.
Visit opensource.com/email-newsletter to subscribe.
GETTING STARTED WITH DEVSECOPS . CC BY-SA 4.0 . OPENSOURCE.COM 15