►
Description
Adoption of DevSecOps Practices in Regulated Industries - Gurpreet Sachdeva
Speakers: Gurpreet Sachdeva
Regulated industries like Aerospace and Automotive follow traditional development practices like V cycle with manual testing and low software reusability. Hardware dependencies and long support contracts have led to a huge legacy codebase with siloed software development teams. Regulated software requires compliance to safety standards like DO-178C, ED-12B, MISRA, ISO 26262, and security standards like DO-326A, ED-202A, SAE J3061, etc. While the DevSecOps emerged from Internet and software companies, it can be used in other industries. This session will cover how incorporating DevSecOps in regulated Industries can optimize software development and reduce security risks. Moreover, it reduces the time from code change to production deployment or release. Rigorous, automated security testing can also validate compliance requirements.
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
A
A
There
is
a
growing
usage
of
software
in
different
industries
and
regulated
industries,
face
unique
challenges
and
adoption
of
devsicops
and
agile
practices,
while
devsecops
emerge
from
internet
and
software
companies.
The
same
principles
can
be
used
in
other
industries
as
well
to
increase
throughout
throughput,
reduce
cycle
time
and
perform
continuous
security,
verification.
A
A
A
A
Modern
cars
have
become
like
a
computer
on
wheels
for
a
comparison
fighter.
Jets
in
world
war
ii
did
not
have
any
software,
whereas
modern
fighter
jets
have
eight
million
lines
of
code.
It
becomes
pertinent
that
the
regulated
industries
start
combining
the
best
practices
and
strategies
of
a
software
company
to
make
successful
products.
A
A
A
As
you
can
see,
there
are
apparent
contradictions
between
the
philosophy
of
agile
manifesto
and
the
way
regulated
software
is
typically
built.
This
has
led
to
delay
in
adoption
of
agile
and
devops
practices
in
regulated
industries.
There
are
some
unique
challenges
which
we
see
when
we
want
to
adopt.
Devsicops
practices
in
regulated
industries,
first
and
foremost,
regulated
industries
like
aerospace,
automotive
and
life
sciences,
etc,
must
comply
with
various
safety
standards.
Like
do
178c
td,
12b,
mysra,
iso,
26262,
etc,
any
compromise
and
safety
standards
can
lead
to
drastic
consequences.
A
A
A
A
Often
fixing
these
vulnerabilities
can
lead
to
design
changes
also
many
times.
This
leads
to
delay
and
release
cycle,
but
with
the
increased
adoption
of
agile
practices,
the
release
cycle
has
shrunk
to
spring
boundaries
of
two
or
three
weeks
so
performing
security
checks.
After
every
few
months
increases
the
risk
of
attackers
exploiting
weaknesses
in
the
production,
security
verification
is
required
to
be
done
continuously
in
the
devops
pipeline.
Hence
the
need
for
devsecops
with
continuous
security
verification
done
throughout
the
ci
cd
pipeline.
A
Similarly,
automotive
industry
has
to
comply
with
iso
26262
safety
standards,
maisra
and
search
for
security
and
autosar
for
coding.
As
you
can
see,
there
are
similar
standards
we
followed
in
other
industries
as
well.
When
we
start
using
agile
and
devsecours
practices,
we
have
to
make
sure
that
eventually
software
is
complied
with.
All
of
these
standards.
A
A
As
for
a
mckenzie
report,
it
is
expected
by
2030,
while
the
software
complexity
in
automotive
sector
will
increase
to
five
times
a
software
development
productivity
will
increase
only
to
two
times
model
based
software.
Engineering
in
recycle
is
a
traditional
way
of
development
in
many
industries
like
aerospace
and
automotive.
A
A
A
A
A
A
Legacy
version
control
systems
are
still
being
used
like
there
are
many
systems
I've
seen
in
my
experience,
they're
still
using
clear
case
in
automotive
and
aerospace
industries.
But,
as
we
all
know,
this
version
control
systems.
These
legacy
version
control
systems
are
not
natively
suitable
for
ci
cd
pipeline
and
have
limited
integrations
with
modern
third-party
tools.
A
So
the
need
of
the
r
is
to
migrate
to
a
modern
version,
control
systems
like
git
or
maybe
bit
bucket,
which
integrate
much
better
with
the
ci
cd
pipeline
and
modern
plugins,
auto
generated
code
shall
be
compiled
and
the
binaries
can
be
stored
in
a
repository
like
artifact
3.
This
is
done
to
make
sure
that
we
don't
need
to
compile
the
automated
code
every
now
and
then
the
next
thing
is
that
we
need
to
optimize
the
branching
strategy
to
ensure
that
future
or
release
branches
are
more
frequently
merged
back
into
the
master
branch.
A
A
A
Since
we
are
increasingly
using
third
party
in
open
source
software
software
composition,
analysis
is
essential
to
create
a
package
build
of
materials.
You
can
see
wonderful
packages
and
associated
warnings
by
looking
at
your
bomb
unit.
Tests
can
be
triggered
as
soon
as
any
new
source
for
changes
are
committed.
A
A
A
Analysis
can
be
used
to
enforce
the
organization's
open
source
software
policy
and
create
a
list
of
third-party
software
being
used.
Configure
your
ide
with
appropriate
static
analysis
tools
which
can
run
during
compilation.
So
you
will
come
to
know
of
potential
vulnerabilities
and
error
prone
code.
A
Vulnerability.
Testing
can
be
done
during
integration
testing
phase
to
find
out
potential
vulnerabilities
and
estimate
the
magnitude
of
risk
in
penetration
testing
perform
full
risk
assessment
by
simulating
attacks
to
identify
exploitable
weaknesses,
as
well
as
trends,
follow
the
fail,
fast
principle
and
whenever,
at
any
stage,
security
vulnerabilities
are
found,
stop
the
pipeline,
fix
the
issues
and
then
move
ahead.
A
When
we
are
working
with
specifically
with
aerospace
software,
we
have
to
comply
with
vo178c
safety
standards,
and
one
of
the
very
fundamental
requirements
is
to
have
a
bi-directional
requirement:
traceability
across
all
phases.
If
you
want
to
comply
with
the
do
178c
standards,
so
bi-directional
requirement
usability
ensures
coverage
of
requirements
in
design
and
code,
and
similarly,
there
is
coverage
of
design
and
code
in
the
requirements,
while
traditionally
it
is
being
done
manually
in
excel
sheets
or
with
tools
like
doors.
A
Source
code
and
unit
test
code
can
contain
you,
the
story
id
and
reference
to
design
model.
Automated
scripts
can
link
user
story
to
code
change
on
code
comment
test.
Automation
tools
can
be
integrated
with
a
common
tool,
test
asset
management
tool
or
repository
where
all
test
scenarios
test
scripts
and
associated
results
can
be
stored
and
traceability
established
back
to
code
requirements
and
effects
after
deploying
to
production
in
case
of
a
defect
or
incident
map
the
defect
id
to
the
requirements,
the
generated
documentation
should
contain
reference
to
requirements
and
design
sections.
A
A
Real-Time
computer
based
models
used
as
virtual
representation
of
physical
systems,
real-time
capable
model
of
the
control
and
the
plant.
For
example.
As
you
can
see
in
this
slide,
you
can
see
there's
a
flight
simulator,
which
is
there,
which
is
trying.
We
are
trying
to
do
a
hardware
loop
simulation
by
using
a
flight
simulator.
A
The
benefits
which
we
can
get
from
hardware
in
loop
simulation
are
less
expensive
for
design
changes
as
hardware
and
loop
simulation
can
be
performed
earlier
than
validation
in
the
workflow
in
order
to
identify
and
redesign
through
problems
relatively
early
in
the
project,
less
expensive
to
schedule.
Hardware
in
loop
simulation
and
more
practical
than
validation,
because
you
can
set
it
up
to
run
on
its
own.
A
Just
like
manufacturing
processes
contain
policies
for
ensuring
and
products
exhibit
strong
quality
characteristics.
Similarly,
embedded
software
should
be
developed
in
accordance
with
policies
that
clearly
state
quality
goals
and
compliance
with
goals
should
be
automatically
ensured.
A
central
cicd
pipeline
enables
software
deployment,
along
with
continuous
security
verification.
A
Sprint
planning
can
be
done
after
backlog
creation
and
prioritization.
You
can
continue
with
traditional
tools
like
those
or
start
using
more
popular
ones.
Like
jira
for
team
collaboration.
You
can
use
tools
like
slack
requirement.
Modeling
should
be
followed
with
design,
modeling
and
software
architecture.
A
Now
documentation
is
another
aspect
which
is
very
important
for
safety.
Compliances
like
do178c,
but
rather
than
creating
big
upfront
documentation,
generate
incremental
documentation.
Every
sprint
in
cicd
pipeline
inputs
can
be
requirement.
Model
system,
model,
component
design,
model,
test
plans
and
source
code.
A
Documentation
directly
generated
from
source
code
keeps
the
documentation
consistent
with
the
source
code.
Additional
documentations
can
be
manually
created
as
part
of
software
design.
Also
consider
security
aspects
and
use
techniques
like
thread
modeling
and
data
flow
diagrams
source
code
can
be
auto
generated
from
design
model
or
self
written,
using
various
kind
of
tools
like
adder,
core
matlab,
simulink,
etc.
These
are
all
traditional
tools
which
people
have
been
using
in
regulated
industries
from
from
a
long
time
back.
A
Unit
testing
should
be
completely
automated
during
implementation,
perform
static
analysis
and
source
code
composition.
There
are
a
lot
of
tools
from
which
you
can
choose
from
the
generated.
Binaries
should
be
versioned,
tagged
and
stored
in
the
repository
like
jfrog
or
artifactory,
deploy
the
binaries
on
integration,
environment,
leveraging
simulations
like
softening
loop,
hardware,
loop
and
even
digital
twins
for
that
matter.
A
A
Unlike
a
sas
environment,
the
software
cannot
be
automatically
deployed
on
the
production
environment,
which
can
be
an
actual
aircraft
or
an
automobile
in
this
case,
so
this
step
would
be
manual
and
the
end-to-end
test
cases
can
be
run
to
verify.
Everything
is
working.
Fine
devsecops
not
only
implies
shift.
Left
of
testing
does
also
shift
right
of
feedback
after
performing
different
types
of
testing.
Any
defect,
suggestions
or
enhancements
should
be
recorded
in
a
tool
like
jira
by
performing
different
activities
in
an
automated
ci
cd
pipeline.
A
So,
in
summary,
by
following
devsecours
practices,
we
do
see
tremendous
benefits
in
terms
of
throughput
stability
and
security,
verification,
the
regulated
industries
like
aerospace
and
automotive
and
life
sciences
can
leave
registered
fc
cost
practices.
Just
like
the
web
companies.
There
are
unique
challenges
in
terms
of
standard
compliance,
security
and
legacy
development
practices.
A
A
A
So,
while
we
are
waiting
for
questions
in
the
chat
window,
there
are
certain
key
things
that
generally
people
ask
me
whenever
I
discuss
this
topic
with
them.
You
know,
like
you,
know,
adoption
of
deficit
cost
practices
for
regulated
industries.
First
and
foremost.
You
know
people
have
a
concern
that
hey.
You
know
what
devops
is
something
which
people
associate
typically
with
a
sas
software
model,
but
can
it
be
used
for
software
which
you're
running
on,
let's
say
an
aircraft
or
an
automotive
so
hell?
Yes,
we
can
do
that.
A
Obviously
you
know
we
will
not
be
able
to
do
an
automated
test
on
aircraft,
but
certainly
we
can
have
simulators
virtual
prototypes.
We
can
have
digital
twins,
which
can
you
know,
really
help
us
in
doing
a
continuous
delivery.
As
such,
it
may
not
be
continuous
deployment,
but
we
can
do
quite
a
lot
of
automation,
end-to-end
testing
security,
verification
and
compliance
verification
in
a
pipeline.
A
So
we
have.
We
do
have
a
question.
So
the
question
is
that
what
does
imply
the
manual
process
of
relating
production,
which
is
a
plane
for
car
yeah?
This
is
you
know
what
I
was
trying
to
say
just
now
that
obviously
this
is
not
like,
let's
say
a
cloud
environment
or
a
sas
environment
where,
from
let's
say,
staging
or
qa,
you
can
directly
deploy
your
software
in
the
production
environment
right.
A
It's
not
like
amazon.com
that
you
have
production
tenant
and
you
can
deploy
directly
over
there
here
we're
talking
about
an
actual
a
car,
for
example.
You
would
not
be
able
to
do
that
automatically.
You'll
have
to
run
the
emitted
software
in
some
kind
of
a
chip,
and
then
you
know
deploy
that
put
that
on
the
aircraft,
and
that
is
why
that
last
step
is
manual
which
cannot
be
automated.
A
That's
the
point
here
and
while
we
are
waiting
for
some
more
questions,
you
know
another
aspect
which
comes
into
mind,
which
people
generally
ask
is
that
when
we
talk
about
aircraft,
etc
and
automotive,
for
that
matter,
the
safety
is
a
paramount
concern
and
there,
of
course,
as
I
mentioned
in
the
talk,
also
that
there
are
different
standards,
for
example,
do
178c
to
follow
when
you
want
to
make
safe
software
the
way
we
have
been
doing
this.
The
way
industry
has
been
doing
that
has
been.
A
You
know
really
manual,
people
have
been
doing
code,
reviews,
walkthroughs
and
then
auditors
come
and
then
do
a
safety
analysis
and
they
go
through
the
code
pieces
but,
as
I
said
earlier,
if
we
use
policies
to
define
our
architecture,
our
design
and
then
throughout
the
sdnc
throughout
the
agile
devops,
you
know
process
the
pipeline.
We
take
certain
measures.
They
can
do
most
of
the
things
in
automated
manner.
A
For
example,
you
can
have
your
documentation,
which
is
a
key
part
of
safety
worthiness
that
can
be
generated
automatically,
as
part
of
let's
say
comments
in
the
code.
As
part
of
your
incident
repository,
there
are
tools
available
which
can
pull
those
comments
and
generate
documentation
for
you.
There
would
be
some
extra
steps
required
after
that,
which
can
be
done
later,
but
much
more,
so
the
part
can
be
done
through
this
then
y
directional
requirement.
Traceability
is
another.
A
You
know
thing
which
can
be
done
automatically
as
part
of
your
pipeline
by
tracing
it
through
your
core
design
requirements,
etc.
So,
all
in
all,
you
know,
the
concept
of
ci
cd
can
be
used
to
make
safer
software
for
regulated
industries
with
that.
I
think
we're
running
out
of
time,
I'd
like
to
thank
everybody
again
for
attending
this
session,
and
hopefully
you'll
get
some
insight
out
of
it.
Thank
you
so
much.