►
Description
While it may not be obvious, both Government and Industry face the same challenges:
- Responsiveness to changing conditions to bring new features and functions to market
- Need to keep ahead of competition / threats
- Security risks and posture
- Rapid time to deliver
Join us as Nicolas Chaillan, Chief Software Officer for the U.S. Air Force, who has been instrumental in leveraging DevSecOps in exciting new ways, highlights some of the innovations that the USAF has implemented, such as:
- Software Factory Concept
- Setting up off-base teams to address specific software requirements
- Engaging Interns and enlisted/employees in the process
- Hardened Software Images
- Repository of Government approved, hardened software
- Process to submit and obtain approval
- Best Practices in Government and Regulated industries to adopt this new paradigm of software development
80+ speakers from 20+ industries presenting over 8+ tracks: All for free. Belong to a community of people passionate about DevOps.
Speaker: Nicolas Chaillan - Chief Software Officer, US Air Force
Get in touch with Sales: http://bit.ly/2IygR7z
A
A
He's
trying
to
drive
all
of
that
from
the
perspective
of
his
background,
in
that
he
is
a
entrepreneur
having
started
over
12
different
companies
and
shipped
and
developed
over
180
different
software
products.
So,
as
nicholas
brings
that
perspective
to
the
air
force,
I'm
excited
to
learn
more
from
him
nicholas.
B
We
have
to
bring
it
with
us
even
to
space
and
then,
of
course,
with
quite
a
few
sensors
and
all
of
that
with
all
these
people's
help.
So
that
makes
our
life
pretty
easy
and
that's
why
we
created
the
beauty,
enterprise
dev
stick-ups
initiative,
which
is
a
joint
team
across
dod
to
bring
an
agnostic
stack,
dev
setup
stack
to
the
dod
by
leveraging
open
source
software
with
kubernetes,
with
oci
compliant
containers.
B
And
really
you
know.
I
think
the
critical
aspect
of
this
was
to
bring
enterprise
scale
services
and
that's
why
we
created
two
teams
file
one
and
platform,
one
file.
One
is
our
cloud
office
bringing
unclassified
and
classified
cloud
access,
and
then
we
have
platform,
one
which
is
agnostic,
which
can
run
on
premise
at
the
edge
on
classifier
environments,
on
the
on
the
weapon
systems
on
the
business
systems.
B
B
Everything
we
do
is
containerized,
so
we
centrally
acquit
it
and
harden
continues
using
also
a
zero
trust.
Behavioral
detection
stack
when
it
comes
to
cyber
and
that's
really
the
second
piece
of
that
cycle.
For
us,
it's
not
just
static,
dynamic
credit.
Everyone
does
that
we
bring
next
generation
behavior
zero
trust
cyber
baked
it
in
to
the
the
community
stack
using
a
service
mesh
like
istio.
B
We'll
talk
a
little
bit
about
that
today.
We
have
to
train
quite
a
few
people.
We
have
a
hundred
thousand
people.
We
have
to
train
over
a
year
so
we're
bringing
self-learning
capabilities
and
biased
content
that
is
not
pushing
one
product
versus
the
other,
very
important
for
us
to
be
agnostic
and
be
able
to
be
flexible
and
moderate.
All
and
really
the
concept
of
containers
and
the
concept
of
of
kubernetes
and
the
abstraction
layer
of
communities
is
critical
for
us.
B
I
wanted
to
share
this
website.
Software.Mail
has
all
the
content.
If
you
go
into
the
dsop
document,
page
you're
going
to
find
all
the
videos,
all
the
architecture,
design,
the
susquehad
repo
everything
we
do
is
open
tools,
so
the
source
code
itself,
the
the
containers
we
we
have
everything
accessible
to
the
world.
So
it's
a
great
way
to
give
back.
So
it's
a
two-way
street
feel
free
to
always
help
us
as
well,
but
you're
gonna
find
a
lot
of
great
content,
training
content
and
the
source
code
as
well.
B
So
why
did
we
pick
kubernetes?
I
think
it's
very
important
for
us
not
to
get
locked
in
be
abstracted.
So
with
the
cloud-native
computing
foundation,
we
can
really
ensure
that
the
cubase
cholesterol
compliant
at
the
same
time,
containers
become
immutable.
Lego
blocks
that
can
be
swapped
around
and
can
try
different
things,
but
on
top
of
that
commands
brings
a
ton
of
value
when
it
comes
to
resiliency,
with
a
big
thing:
security
stack
with
what
we
call
the
cycle,
internal
security
stack
and
we'll
talk
about
what
that
brings.
B
B
When
you
look
at
the
complexity
of
the
dev
setup
stack
and
that's
just
one
example-
we
have
dozens
of
different
pipeline,
but
if
you
think
of
all
these
moving
parts
and
lego
blocks,
if
you
had
to
use
the
amps
to
obey
and
get
access
to
the
latest
bits
of
all
these
moving
pieces,
you
would
pretty
go
nuts
pretty
quickly.
And
so
we
are
using
containers
to
centrally
scan
and
approve
and
accredit
these
containers
and
also
harden
the
containers
using
layers,
and
so
they
use
the
same
os.
B
But
for
companies
it's
also
very
easy
to
get
their
software
accredited
as
well.
So
everything
we
do
is
containerized.
Everything
is
moving
target
defense,
that's
a
fancy
way
to
say
we
we
treat
like
cattle
and
not
pets,
so
we
can
kill
everything
and
bring
it
back
up
multiple
times
a
day
as
needed,
which
is
a
great
way
to
stop
bad
tools
from
sustaining
access
to
systems
by
going
back
to
immutable
state
and
killing
the
stack
regularly.
You
end
up
creating
that
concept
of
moving
target
defense.
B
When
you
look
at
layers,
we
want
to
add
credit
layers
and
swap
layers
as
needed,
so
we
have,
of
course,
the
cloud
layer
on
premise
or
weapon
layer
wherever
the
application
is
going
to
run,
and
on
top
of
that
we
have
kubernetes,
which
could
be
any
cncf
approved,
commands
cluster,
and
then
we
have
the
the
ci
cd
pipeline
on
top
with
172
containers.
That's
pretty
amazing
today
and
it's
growing
fast.
On
top
of
that
we
have
the
service
mesh.
A
B
So
10
left
of
the
nest
853
controls,
so
they
easy
way
for
the
application
teams
to
implement
the
delta
of
those
streamlining
access
to
the
country's
monitoring
stack,
which
brings
that
confused
monitoring
aspect
platform.
One
is
kind
of
this
central
enabler
of
all
these
teams.
We
have
so
many
teams
building
software
across
dod.
We
have
software
factories
as
we
call
them.
We
have
scientific
technology,
research
organizations,
we
have
partners
outside
of
dod
inside
the
defense
industrial
base.
B
We
have
tons
of
ventures
and
non-traditional
startups
and,
of
course,
partners
outside
of
the
dod
with
other
agencies
as
well,
and
so
all
of
these
teams
can
now
have
access
to
platform.
One
and
you'll
see
we
bring
different
options
when
it
comes
to
streamlining
access
to
pipelines
all
the
way
to
production
environment
as
well.
B
Some
of
the
fancy
names
we
have
that
build
different
type
of
software
across
dod,
I'm
sure
most
of
you
would
love
to
go
and
work
for
tron
in
hawaii,
a
pretty
good
good
place
to
be,
but
here
are
kind
of
the
list
of
services
and
I
think
for
any
organization,
that's
trying
to
scale
their
psych
ups.
I
think
it's
critical
for
them
to
understand.
We
have
to
bring
that
scale,
managed
service
concept
and
really
reaper.
One
is
the
source
code
report
for
us
everything.
B
Is
there
whether
it's
the
the
community's
distributions?
We
harden
the
isc
to
spin
up
the
environment.
All
the
containers,
who's
good
there
and
bank
is
the
binary
side
of
that.
So
we
have
now
way
more
containers.
We
have
120
continuous,
approved
170
by
the
end
of
the
month,
so
great
bank
of
hardin
bits
that
are
signed
by
dod
and
can
be
used
by
anybody.
This
is
open
to
the
world,
so
iron
bank
is
accessible
from
internet
and
then
we
have
as
well
the
hardened
distros
command.
B
Distro
openshift,
with
rancher
with
a2
iq,
will
be
here
with
all
with
acacia,
so
people
can
go
and
and
take
that
code
and
run
with
it,
and
it's
already
passing
the
duty
requirements.
It's
already
hardened
the
way
we
want
it
to
be,
and
we
go
a
little
bit
beyond
the
the
cis
benchmark.
We
do
a
lot
of
pretty
cool
stuff,
so
check
it
out.
It's
all
on
these
links
and
then
the
two
main
concept
of
platform.
B
One
is
the
party
bus
and
the
big
bang
and
that's
pretty
important,
I
think,
for
a
bigger
organization
that
I'll
bring
to
streamline
access
to
their
psychops.
You
need
probably
both
of
these
models
based
on
the
size
and
the
complexity
of
the
teams.
The
potty
bus
is
a
multi-tenant
environment,
so
we
host
it.
We
manage
it.
We
we
run
everything.
We
pick
the
tools
they,
the
teams
only
get
their
to
the
environment.
B
They
don't
get
to
pick
the
tools.
They
don't
get
to
manage
the
tools.
There's
a
cost
per
double
per
month
at
multiple
classification
levels,
for
us
of
course,
but
that's
space
specific
to
the
dod
and
then
the
big
bang
is
kind
of
a
dedicated
instance
of
platform.
One
into
a
specific
environment
could
be.
Your
cloud
could
be
on-premise
to
do
hollow-in-the-loop,
testing
or
could
be
on
the
classified
cloud,
and
really
they
get
to
pick
the
tools
it's
customized
based
on
their
needs.
B
Based
on
the
mission
need
we
support,
16
programming,
languages,
23
databases,
so
they
get
to
pick
what
works
for
them
and
it's
customized
to
their
mission.
That
is
really
the
prime
enabler
of
larger
teams.
The
party
bus
can
also
be
used
for
training
and
get
people
started
with
devsecops
when
you
don't
don't
know
much
about
it
and
they
have
to
have
a
sandbox
playground
and
the
party
bus
is
a
great
option
for
that.
On
top
of
that,
we
we
started
building
quite
a
few
training
options.
B
Changing
for
teams
that
are
just
getting
started
that
are
struggling
to
understand,
test
driven
development
user
center
design.
All
these
foundational
concepts
when
it
when
it
comes
to
agile
and
devsecops,
and
particularly
also
the
the
getups
mindset
of
everything,
is
code
and
no
drift
in
production.
So
networking
changes
cyber
patching.
All
these
disappear
and
become
code
change
and
get
that
gets
pulled
by
qa's
from
from
the
git
repo.
We
don't
push
we'll
talk
about
that
as
well.
We
have
pen
test
services
and
we
even
brought
contract
vehicles
right.
B
B
B
They
happen
containers,
obviously
they
won't
be
any
cve,
so
none
of
the
scanning
cv
tools
will
bring
much
value
there.
That's
why
we
look
at
behavior
to
see
if
the
container
is
doing
things
it's
never
done
before
and
proactively
kill
the
container
in
that
case,
or
alert
a
lot
of
the
teams
to
take
a
look
at
what's
going
on,
and
then
we
have,
of
course,
a
huge
huge
use
case
with
chaos,
engineering
and
chaos.
B
Engineering
is
all
about
crashing
stuff
to
see
how
resilient
the
system
can
be
and
very
important
to
know
how
many
of
your
containers
are
critical
to
your
mission.
Not
everything
is
critical
should
be
critical.
If
you
build
the
right
micro
service
architecture,
you
can
have
different
services
with
caches
and
and
more
clean
behavior
when
it
comes
to
graceful
termination.
B
B
All
these
libraries
can
become
very
toxic
very
quickly
and
have
to
be
shared
across
teams,
and
so,
if
you
move
to
a
service
mesh
like
history,
with
a
cycle
container
concept
that
is
not
inside
the
container,
but
alongside
the
container,
you
can
update
these
capabilities
independently,
and
so
we
will
bring
istio
to
be
able
to
do
service
discovery,
authentication,
a
b,
testing
kind
of
release,
fault
injection,
of
course,
east-west
traffic
management.
So
for
container
h,
dr
b,
it
has
to
be
white
listed.
That's
very
important
for
zero
trust.
You
reduce
the
attack
surface.
B
So
the
key
concept
of
iac
and
fastps
code
is,
you
know,
and
the
key
benefits
as
well
is
no
drift
between
environments
right.
It's
immutable.
It's
predictable!
It's
automated,
ideally,
no
human
in
production,
so
you
can
disable
pulse.
You
can
disable
ssh,
there's
no
configuration
drifts,
everything
is
code,
playbooks,
networking
tests,
configuration
changes
and
you
do
your
change
management
with
get,
and
so
git
becomes
your
source
of
truth
and
that's
very
critical
to
understand
that
if
someone
managed
to
tamper
with
your
source
code,
you're
done
right.
So
everything
is
code.
B
Everything
is
part
of
that
change.
Management
of
merge
requests,
pull
requests
based
on
how
many
set
of
eyes
you
need
to
approve
code
change
that
will
define
how
you
mitigate
with
insider
threat
and
also
ensure
that
there
is
a
proper
change
management
in
place
before
allowing
anyone
to
just
make
code
change.
But
in
effect,
both
your
testing
teams
and
your
cyber
teams.
A
B
Developers
they
have
to
make
code
change,
you
don't
just
log
in
into
ssh
and
start
patching
stuff.
You
make
that
change
in
code,
which
will
then
trigger
the
pipeline
to
run
the
proper
assessment,
linting
testing
and
then
the
the
part,
the
staging
environment,
will
pull
from
git
and
do
its
own
tests
again.
And
then
your
production
environment
will
then
pull
from
git
again
from
a
different
branch.
B
Your
master
brand
to
pull
that
change
to
employment,
and
so
when
we
started
to
move
to
get
ups
and
we
realized
everything
is
code
that
even
means
you'll
steal
secrets.
You
can
have
cl
secrets
which
is
encrypted
secrets,
don't
put
your
secrets
and
encrypt
it
into
your
source
code,
but
you
can
use
seal
secrets.
You
can,
of
course,
use
vault
capabilities,
but
then
you
also
have
the
ability
to
have
a
full
desired
state
and
declarative
manifests
in
your
git.
B
That
gives
you
the
ability
to
do
rollbacks
by
just
you
know,
doing
a
code
rollback
full
configuration
management
disaster
recovery
is
also
streamlined,
because
now
what
you're
looking
at
is
backing
your
source
code,
repo
and
your
databases,
and
you
have
everything,
because
everything
is
in
code
other
than
your
data
and
then
we
use
pools
and
not
pushes
and
that's
critical.
I
think
a
lot
of
people
that
move
to
cicd
start
with
you
know
jenkins
or
gitlab
ci
or
whatever
ci
cd
tool
you're
using
to
push
into
your
staging
of
production
environment.
B
That
is
a
non-starter
for
us.
We
don't
want
a
push
because
then
your
cicd
tool
has
the
keys
to
your
production
environment
and
that's
that's
a
no-go.
We
want
to
do
it
as
a
pool.
In
effect,
we
have
a
timer.
How
often
as
you
want
that,
will
come
and
check
your
git
to
see
if
there's
any
changes
and
apply
those
changes
with
algo
cd
today,
to
do
that,
we
we
can
cut
into
smaller
repos.
You
could
have
a
repo
per
container
and
then
you
have
a
even
a
service
mesh
repo.
B
B
Many
many
cyber
tools,
if
you,
if
you
use
any
of
those
fancy
cyber
container
security
tools,
they
all
very
much,
even
even
cubase
dashboards
and
capabilities
on
service
meshes,
they
all
have
fancy
dashboards,
that
let
you
make
changes
in
your
production
cluster
and
that's
a
non-starter,
we're
just
pushing
the
wrong
behavior
and
educating
people
to
do
the
wrong
things.
They
should
never
be
allowed
to
make
changes
in
production.
B
What
the
those
tools
should
do
instead
is
the
merge
requests
into
that
gateway
pro
proactively,
pushing
code
change
based
on
the
issue
fund.
So
if
a
cyber
tool
finds
an
issue
with
a
container
with
a
yaml,
whatever
the
case
may
be,
instead
of
making
the
change
in
production,
they
should
push
that
could
change
back
map
it
to
the
source
code.
Repo
find
the
right
file
to
change
in
git,
based
on
the
finding
on
the
cyber
finding.
B
So
first
map
map
your
cisco
report
with
your
production
stack,
tell
you
which
file
to
go
and
change
and
potentially
even
propose
proactively
the
change
to
fix
the
code,
and
then
you
just
have
to
approve
the
merger
requests
and
in
fact
you
automated
the
the
process,
and
so
that
is
probably
the
future
of
cyber
tools.
But
many
many
tools
are
still
very
much
focused
on
providing
visibility
and
making
change
in
production,
and
so
that's
where
it's
known
started
for
me
to
use
these
features.
B
You
want
to
disable
that
and
not
let
people
make
change
in
production.
What
is
also
interesting
for
us
is
we
have
this
concept
of
authority
to
operate?
You
know,
authority
tour
for
ato
is
a
very
lengthy
process
can
takes
eight.
You
know
eight
to
16
months,
for
software
to
be
accredited
to
running
products.
B
Whatever
and
and
of
course,
when
you
wait
for
you
know
years
of
software
development
to
do
this,
it
becomes
a
very
cumbersome
process.
By
doing
it
incrementally
multiple
times
a
day
and
using
the
principles
of
devsecops
you,
you
streamline
that
and
we
managed
to
save
a
hundred
year
of
program
planned
time
within
one
year
of
moving
to
deaf
psychops,
with
only
37
programs
and
we're
not
60
already.
B
And
then
we
authorize
the
teams,
the
people
that
are
going
to
be
using
the
factory,
because
they
also
need
to
have
specific
training
and
they
need
to
really
have
the
right
clearances
and
be
able
to
have
the
cyber
background
to
understand
the
gates.
And
now
you
have
a
con
to
save
here,
and
that
is
obviously
game.
Changing
for
the
department
being
able
to
move
at
a
pace
of
relevance.
B
How
do
you
whitelist?
So
we
created
an
open
source
project
that
helps
aggregate
cyber
findings
and
whitelist
findings
per
layer,
and
then
you
can
not
have
to
re-re-authorize
cve
that
you
had
to
whitelist
for
that
specific
layer.
So
again
we're
really
trying
to
give
back
to
the
community
and
open
tools,
everything
we
do
that
we
can
open
tools.
B
So
it's
pretty
exciting
to
see
the
the
beauty
be
flexible
enough
to
to
get
there
and
we
love
to
have
you
guys,
join
us
and
participate
in
those
projects
and
and
have
a
community
growing
around
these
capabilities.
We
have
all
these
containers,
these
hotend
containers.
We
have
this
cv:
whitelist
capability,
aggregation
capability
per
layer
for
content,
layer
very
interesting
as
well,
so
really
wanted
to
share
the
email.