//////////////////////////////////////////////////////////////////// t cht lk
In DevSecOps, we should be
encouraging our teams to fail – often
and quickly – because it is only
through experiencing and observing
failure that our applications and
projects will improve.
Nobody believes anymore that systems
or applications are invulnerable: it’s not
a case of if you will be attacked and
breached but when.
Design your processes around that:
monitor for abnormal behaviour, be
ready to mitigate, but most of all, ensure
that you have processes to learn from
what went wrong and build a better,
more robust and more resilient project –
and team – in the next iteration.
www.intelligentcio.com
“
DEVSECOPS TEAMS SHOULDN’T
BE INSULATED FROM OTHER
PARTS OF THE ORGANISATION .
Wrapping up
I don’t want to pretend that there are no
similarities between DevSecOps and sport:
there are, of course, many overlaps.
Some of the more obvious examples
are how making a major change takes
commitment from top-down as well as
bottom-up; the importance of building a
team whose members can communicate
well with each other; and the ability to react
to threats in real-time.
I’m never going to suggest that it is all
about difference. But sometimes it’s as
eye-opening comparing something to an
opposite than to an equivalent. n
INTELLIGENTCIO
89