[Music]
hi everyone uh I'm Pina from runtime
verification and today I'm going to
present our comprehensive approach to
security that we have R RV because I
believe that it's it can significantly
improve the security stance of projects
and even make it more sustainable for
them um I'd like to represent this
project as a pyramid where lower layers
uh enable or at least make easier to get
the higher lay layers right and
currently the standard is to implement
the code and just hand it over to some
external auditor or a contest for a
one-off audit or code review and while
it is a pretty good Baseline it also
doesn't do much in terms of continuous
security assurance and that is very
important especially for protocols under
active
development um if the team has resources
or feels like it uh some projects also
have some documentation outlining what
the code um is actually supposed to do
or even use some tooling um to do unit
testing or fuzzing and while the
completeness of those is very much
hindered by the constraints in um devel
the development process um having more
complete documentation and some tests
actually makes helps make sure uh that
the audit is actually going to go well
because it adds an additional Dimension
to it since the auditor can not only
check for some common vulnerabilities
but also uh for the adherence of the
code to the business law project uh that
they're supposed to
implement um and having tests obviously
is good too uh a more comprehensive
approach however uh add some more layers
and maybe counterintuitively we actually
think that it makes the security model
more sustainable and uh one of the steps
that is often overlooked is the design
review that's where some person an
auditor looks through the design
understands what the project is actually
supposed to do and um how does the
architecture looks like and sees if it
actually makes sense because if the
design doesn't um then none of that
matters actually because the protocol
can still be compromised and the good
byproduct of that is that it also allows
you to write Better Properties and
specification outlining what the Cod is
should or should not do and once
formalized in the forms of tests or
proofs we that actually enables uh the
application of more advanced tooling we
can have more complete fuzzing test SS
we can do formal verification for even
better security guarantees and the best
part of that is that we can also run
them on CI and I generally believe that
having automated security processes um
is good eding more automation is better
because it makes it harder to just skip
through certain steps it ensures that
the the security protocol is actually
followed consistently and also CI in
that sense works as sort of an automated
audit that is going to be run on every
PR or every commit uh and um well that's
less expensive than having a human looks
through it over and over again so as an
example of
something um that
as an example of how it is important to
follow through this whole process I have
this well example that mayor may not be
based on a recent hack and that happened
to the protocol that uh helped users
convert their BDC into an equivalent
amount of R BDC that we'll call Defcon
BTC and it was running on BTC chains so
it was supposed to work with Native
tokens but it was also running on other
networks which had ethereum as a native
token and there was a change that
actually made it possible for users to
Mint uh an equivalent amount of Defcon
BDC for eer and iser is like 20 times
cheaper so the hacker actually just made
it a lot of free money basically and the
thing is there was a property that just
hasn't been informed or maybe hasn't
been formulated that the user should
also not be able to convert non BTC
tokens into U well the rupt version of
BTC and this property could actually
have been enforced with something as
simple as a unit test or this fuzzing
test that you can see on the slide um
that just checks that if um the protocol
is running on ethereum Main net then
whenever someone tries to Mint tokens
using eer um this transaction fails uh
so that is a Foundry test uh has it been
running on CI it maybe could have caught
um the issue as soon as this code was
pushed but before the
deployment uh so to summarize the points
I want to make here is that security is
complicated I think everyone knows it
there are a lot of steps in this process
it's very important to get all of them
right um automation is very useful
because it helps Ure sure uh that the
process the security process is followed
um consistently and is enforced and in
addition CI also provides a very
efficient and a very cost effective um
way to ensure that new updates don't
break anything uh one last thing that
has been missing so far is this base
layer which I haven't really touched in
detail that is uh obsc because
unfortunately there have been a lot of
private key compromises um in the past
year and if the private key is
compromised then unfortunately even have
very secure smart contract code uh can
also be
exploited and and there are a lot of
resources about how to get it right on
the internet so I encourage all of you
um to look through it and yeah thank you
very
much thanks
[Applause]
Pina any questions for
pina I guess my one question would be
around maybe fatigue in terms of
continuing to be diligent about making
sure that the basics are in place and
I'm curious for you what has helped to
maintain those habits over
time thank you yeah we try to follow
these processes religiously uh at RV
automation helps a lot because uh you
don't have to you know go over the same
things uh over and over again instead
you write some properties that you
specify some properties and then you
formalize them in the forms of tests or
proofs with a lot of formal verification
so that's that's what we try to set up
and then as whenever code changes that
actually handles it for us uh for a LGE
to a large degree um I think it actually
the having the process makes it
easier cool next uh yeah question on
like uh blockchain security the way you
have Smart contract which is immutable
versus let's say on web 2 where you can
update your code if you discover
security problem after the fact so how
does that factor in Oh you mean
upgradability uh not necessarily but
like let's say you don't have
upgradeability then how would you modify
your security practices such that that
doesn't uh like so that you mitigate
that I guess right got it thank you um
well I guess that's why you try to get
it right the first time before
deployment that's why we advocate for a
very comprehensive security analysis
that you perform before deployment uh to
make sure that you go through all the
stages that the team you know writes
proper documentation helps us formulate
the properties and invariance that
should hold that they can that can later
be monitored um we advocate for like
formal verification to ensure that there
are like the bus security guarantees I
guess there are some there is a field
that that deals with like some posst
Haack things or recoveries um but I
guess that's um that's that's a
different story we just we just suggest
that people should get it right and I
think you know I think I think we're
getting
better cool is there something like the
oosp Zed attack proxy equivalent in
smart contracts or blockchain Frameworks
that you'd
recommend s can you please repeat once
again the O the open web application
standards project The Zed attack proxy
that they have we used to use it in our
CI Tooling in like web 2 sort of
development to test for the top 10 oasp
uh security
vulnerabilities right yeah I haven't
been aware of that but it's it sounds
pretty useful I'm all up for using any
tool in that helps and having it on CI I
guess anything would help static
analyzers are great uh as the first step
especially um having unit tests is also
extremely helpful and very efficient um
fing can uncover a lot of
vulnerabilities so uh yeah thanks for
letting me know about
that okay one more
question thanks um you mentioned like a
design review as a precursor to the
actual code review is your like hope or
expectation from an audit point of view
that a team comes to you with the design
before they even write the code or were
you just talking about that as a
separate a specific phase of the audit
that is perfect but that almost never
happens so the sooner we introduce
security and you know some testing any
of that uh into the process of
development the easier it becomes for
everyone uh that's something that we
have found out ourselves uh but it
almost never happens so we at least try
to allocate some time for design review
first before we dive into the code
itself to make sure that we also
understand what it's supposed to do um
but I mean having the team providing us
the design first is ideal and we can
also like help us help out with the
stages uh but it's pretty rare because
of the resource constraints I guess
great
thanks okay we can take one more
question
if there is
any oh there's one
there thank you uh I would like to know
if uh if there
are some security best practices for
smart contract based on artificial
intelligence thank
you based on artificial intelligence
right yes right um I am aware of a few
tools that do it um I think you can also
Ask Jud to generate you some security
practices uh and it will be pretty
helpful when it comes to like common
vulnerabilities I guess the current
common problem with all this AA based
tooling is that it it is good at pattern
matching right so it can definitely help
you find some common issues that are
known for a long time but it probably
has bigger issues with like business
logic or design review Parts um so I
guess it's it's pretty helpful at least
when it comes to the the first
part thank you
okay that's everything thank you Pina
let's give it up to Pina
[Applause]