WEBVTT

1
00:00:03.930 --> 00:00:05.970
Anna Delaney: Hello, this is
Proof of Concept, a talk show

2
00:00:05.970 --> 00:00:09.480
where we invite security leaders
to discuss the cybersecurity and

3
00:00:09.480 --> 00:00:12.720
privacy challenges of today and
tomorrow, and how we can

4
00:00:12.720 --> 00:00:15.990
potentially solve them. We are
your hosts. I'm Anna Delaney,

5
00:00:15.990 --> 00:00:17.790
director of productions at ISMG.

6
00:00:18.240 --> 00:00:20.040
Tom Field: I'm Tom Field, I'm
senior vice president of

7
00:00:20.040 --> 00:00:22.980
editorial with Information
Security Media Group. Anna, it's

8
00:00:22.980 --> 00:00:25.230
a pleasure to see you. Why
didn't we do this when we were

9
00:00:25.230 --> 00:00:26.340
together last week?

10
00:00:26.990 --> 00:00:29.900
Anna Delaney: Good question! It
was great to see you in New York

11
00:00:29.900 --> 00:00:33.530
for our Financial Services
Summit. But, Tom, this is our

12
00:00:33.530 --> 00:00:37.580
second Proof of Concept episode
on the topic of software supply

13
00:00:37.580 --> 00:00:41.240
chain security. And, just to
recap, for our viewers, on the

14
00:00:41.240 --> 00:00:44.390
first episode, we explored the
state of the software supply

15
00:00:44.390 --> 00:00:48.470
chain, the MOVEit breaches, the
role of SBOMs and transparency

16
00:00:48.470 --> 00:00:52.250
in software development. Now, on
this episode, we are tackling

17
00:00:52.340 --> 00:00:56.330
open-source governance. And,
while immensely valuable, it

18
00:00:56.330 --> 00:00:59.720
also presents several challenges
for organizations and software

19
00:00:59.720 --> 00:01:04.130
developers. So, we'll be diving
into the benefits of OSS

20
00:01:04.130 --> 00:01:07.580
adoption, challenges around
consumption and visibility,

21
00:01:07.700 --> 00:01:11.990
vulnerabilities on maintained
software and so on. An important

22
00:01:11.990 --> 00:01:15.230
topic, and plenty to talk about.
So, what are you hearing, Tom,

23
00:01:15.380 --> 00:01:18.410
right now, from security leaders
on this subject?

24
00:01:18.510 --> 00:01:20.430
Tom Field: Oh, huge topic! In
just the past two weeks, I've

25
00:01:20.430 --> 00:01:26.040
hosted discussions in Washington
D.C., as well as in Chicago on

26
00:01:26.040 --> 00:01:29.190
this very topic and spoke with
government leaders, and we talk

27
00:01:29.190 --> 00:01:33.090
about the progress that they've
made in the mandates of Biden's

28
00:01:33.090 --> 00:01:36.690
cybersecurity executive order,
and it's like MFA? Check that

29
00:01:36.690 --> 00:01:42.030
box. Zero trust? Check that box.
SBOM? Hmm, not so much there.

30
00:01:42.240 --> 00:01:47.010
And, in talking with prominent
business leaders in Chicago last

31
00:01:47.010 --> 00:01:50.070
week, this is one of the topics
that's most vexing. And, it

32
00:01:50.070 --> 00:01:54.330
comes down to, there is so much
open-source code within the

33
00:01:54.360 --> 00:01:58.740
applications that are in primary
use, and security leaders don't

34
00:01:58.740 --> 00:02:02.940
know where it necessarily is.
They don't know, necessarily,

35
00:02:02.940 --> 00:02:07.020
where it came from. And, they're
wrestling with this question

36
00:02:07.050 --> 00:02:10.680
that we're going to ask of our
guests today. But, it's a

37
00:02:10.680 --> 00:02:13.110
prominent question in the
industry now, which is: Hey,

38
00:02:13.560 --> 00:02:16.230
what's wrong with using free
software that's posted by

39
00:02:16.230 --> 00:02:20.610
strangers on the internet? It's
a tough one. And, it's a source

40
00:02:20.610 --> 00:02:23.850
of so many vulnerabilities
today. And, it's become an area

41
00:02:23.850 --> 00:02:27.300
where the adversaries certainly
are shifting left as well the

42
00:02:27.330 --> 00:02:32.490
defenders are in planting
potential BOMs in the code

43
00:02:32.490 --> 00:02:36.540
that's being used as open-source
components. It's a tough one.

44
00:02:37.140 --> 00:02:39.810
Anna Delaney: Planting potential
BOMs. I love that! But, you

45
00:02:39.810 --> 00:02:42.540
raised some really important
points, and I look forward to

46
00:02:42.540 --> 00:02:44.760
hearing what our experts have to
say. Let's welcome back our

47
00:02:44.760 --> 00:02:48.600
security leaders, Mike Baker and
Chris Hughes, who joined us for

48
00:02:48.600 --> 00:02:51.780
the first part of this series.
So take it away, Tom.

49
00:02:52.080 --> 00:02:54.450
Tom Field: Excellent! It's great
to have them both here. Mike is,

50
00:02:54.480 --> 00:02:58.080
of course, VP and CISO with DXC
Technology. Mike, I'm going to

51
00:02:58.080 --> 00:03:00.270
ask you the same question we
just talked about here, Anna and

52
00:03:00.270 --> 00:03:03.150
I, what is wrong with using free
software that's posted by

53
00:03:03.150 --> 00:03:05.160
strangers on the internet? I
don't see anything wrong with

54
00:03:05.160 --> 00:03:05.370
that.

55
00:03:05.660 --> 00:03:08.270
Mike Baker: I don't know if
there's anything inherently

56
00:03:08.270 --> 00:03:10.610
wrong with it, I think it's a
governance question, right? I

57
00:03:10.610 --> 00:03:12.680
mean, there's a lot of
advantages when you look at,

58
00:03:12.800 --> 00:03:15.080
kind of, open-source software
and the open-source software

59
00:03:15.080 --> 00:03:19.910
community, right? I mean, number
one, cost! Cost is - right?

60
00:03:21.200 --> 00:03:24.020
Generally speaking, a lot of
this OSS, it's out there, you

61
00:03:24.020 --> 00:03:27.080
can use it, it's solves good
business problems, there's large

62
00:03:27.080 --> 00:03:30.380
communities that are backing it
up, right? So, you have

63
00:03:30.380 --> 00:03:33.650
transparency in the code, you
can look at the code, it's not

64
00:03:33.770 --> 00:03:37.130
this black box, like
off-the-shelf software. It

65
00:03:37.130 --> 00:03:40.580
prevents, I would say, companies
from getting in vendor lock in,

66
00:03:40.580 --> 00:03:43.430
right? Sometimes when you get in
these business partnerships, you

67
00:03:43.430 --> 00:03:47.570
get locked into that specific
platform. So, there's a lot of

68
00:03:47.570 --> 00:03:50.840
flexibility options there. So,
there's benefits to companies

69
00:03:50.840 --> 00:03:53.240
using open-source software,
there is absolutely, but it's

70
00:03:53.240 --> 00:03:55.880
more of a right time, right
place, right governance

71
00:03:55.880 --> 00:03:58.610
situation, right? Because there
are certainly a lot of risks,

72
00:03:58.910 --> 00:04:02.540
and you're going to invest to
mitigate those risks, you know,

73
00:04:02.540 --> 00:04:05.120
to make up for the potential
savings or other opportunities

74
00:04:05.120 --> 00:04:07.880
you have using this sort of
software. So, you know, you look

75
00:04:07.880 --> 00:04:11.960
at the top three risks, you
know, just the vendor support

76
00:04:11.960 --> 00:04:16.070
and the updates. When you go out
to an established company, you

77
00:04:16.070 --> 00:04:19.790
know, they have a supported,
sort of, piece of software,

78
00:04:19.790 --> 00:04:21.920
they're looking at it again,
there's problems with that too,

79
00:04:21.920 --> 00:04:26.180
with COTS software. So, it's not
like it's exclusive to OSS. But,

80
00:04:26.210 --> 00:04:29.630
just the consistency of that
support and the updates and that

81
00:04:29.630 --> 00:04:33.140
community dependency, I think is
really important to really dive

82
00:04:33.140 --> 00:04:36.470
into as a released open-source
software. And again, the

83
00:04:36.470 --> 00:04:40.610
trustworthiness of the code, you
have that transparency. People

84
00:04:40.610 --> 00:04:44.270
say, okay, that transparency
automatically equals, you know,

85
00:04:44.900 --> 00:04:48.140
the code is secure. But, you
have to then have the processes

86
00:04:48.140 --> 00:04:52.010
to audit that code, to review
that code; make sure you're

87
00:04:52.040 --> 00:04:55.640
receiving that from a trusted
source, because there's a lot of

88
00:04:55.640 --> 00:04:59.690
adversarial intent to get in the
middle of that pipeline,

89
00:04:59.870 --> 00:05:03.500
introduce malicious software.
So, between the trusted support

90
00:05:03.500 --> 00:05:06.860
and the trusted source and
auditing that code for your use,

91
00:05:07.130 --> 00:05:10.190
you know, you have to do that to
make it trusted. And then, I

92
00:05:10.190 --> 00:05:13.340
think the last thing I want to
point out was just inherently,

93
00:05:13.760 --> 00:05:16.070
again, depending on the
community and the piece of

94
00:05:16.070 --> 00:05:19.130
software, what's the
documentation like, right?

95
00:05:19.130 --> 00:05:21.290
What's the education you have to
do to your user and

96
00:05:21.440 --> 00:05:25.310
administrators to use that piece
of software? That's something,

97
00:05:25.310 --> 00:05:28.430
again, you may have to fill that
gap or that hole related to the

98
00:05:28.430 --> 00:05:32.300
use of that open-source or
freeware software. So, I mean,

99
00:05:32.300 --> 00:05:34.370
again, there's a lot of
benefits. But, when you look at

100
00:05:34.370 --> 00:05:38.060
that, you know, lack of
consistent support, viewing the

101
00:05:38.060 --> 00:05:40.550
code, making sure you're getting
from trusted sources/trusted

102
00:05:40.550 --> 00:05:43.400
communities, making sure the
documentation is up-to-date,

103
00:05:43.430 --> 00:05:46.220
making sure users and your
administrators are educated.

104
00:05:46.490 --> 00:05:48.020
There's definitely a lot of
risks that outweigh the

105
00:05:48.020 --> 00:05:48.920
benefits.

106
00:05:49.520 --> 00:05:51.560
Tom Field: I hear a lot here
about visibility and tracking;

107
00:05:51.560 --> 00:05:53.900
what are some of the specific
challenges that you face when it

108
00:05:53.900 --> 00:05:56.060
comes to consuming and
maintaining open-source

109
00:05:56.060 --> 00:05:56.750
components?

110
00:05:57.830 --> 00:06:00.470
Mike Baker: So, we had talked
about software bill of materials

111
00:06:00.470 --> 00:06:04.220
being the future. And, I'm
really invested in that, I think

112
00:06:04.220 --> 00:06:06.860
it's great thing for the
community, you know, it's a

113
00:06:06.860 --> 00:06:10.130
great thing to bring everything
up to a level of, you know, a

114
00:06:10.130 --> 00:06:14.450
par level of transparency. But,
I don't think we're there yet as

115
00:06:14.450 --> 00:06:17.720
a community, right? I think
number one, and we talked about

116
00:06:17.720 --> 00:06:21.110
this last time, we're really
struggling with the adoption of

117
00:06:21.170 --> 00:06:23.930
SBOM, we're struggling with the
tools that are going to enable

118
00:06:23.930 --> 00:06:27.590
companies like ourselves or our
customers to really look at

119
00:06:27.590 --> 00:06:31.220
that, holistically, across a
large enterprise. And, I think,

120
00:06:31.220 --> 00:06:34.310
thirdly, just to keep it, kind
of, high-level is, you know,

121
00:06:34.310 --> 00:06:37.190
really, the talent that's out
there is really hard to find,

122
00:06:37.370 --> 00:06:39.650
really hard to bring in, and
really hard to keep at the

123
00:06:39.650 --> 00:06:43.670
companies, right? This is a very
unique and specific skill set,

124
00:06:43.670 --> 00:06:46.610
right? There's not much stuff
out there, we do have a lot of

125
00:06:46.610 --> 00:06:50.000
people who can develop code, do
that sort of stuff. With

126
00:06:50.000 --> 00:06:53.540
software supply chain experts,
it's still really an emerging

127
00:06:53.540 --> 00:06:56.870
field, we have one of the top
ones here on the panel. But,

128
00:06:56.870 --> 00:07:00.410
it's an emerging field, and it's
a really unique, I would say,

129
00:07:00.770 --> 00:07:03.890
skill set to have here. And
then, when we look at, kind of,

130
00:07:03.890 --> 00:07:07.520
the tracking, if you take SBOM
out of it, right? We talked

131
00:07:07.520 --> 00:07:10.790
about the updates, right? And,
how like those can be dynamic

132
00:07:10.790 --> 00:07:13.400
and frequent and on different
schedules and on different

133
00:07:13.400 --> 00:07:16.340
libraries. So, where's the
tooling to make sure that the

134
00:07:16.340 --> 00:07:18.620
software is up-to-date, I talked
about that being one of the

135
00:07:18.620 --> 00:07:22.100
risks, but you're talking about
updating different release

136
00:07:22.100 --> 00:07:24.530
schedules for different
libraries and that software,

137
00:07:24.530 --> 00:07:29.390
different versions, right? It
can get very complex quick. And,

138
00:07:29.390 --> 00:07:31.880
you're also talking about a lot
of dependencies in that

139
00:07:31.880 --> 00:07:34.340
software, you know, if you
update this, does it break a

140
00:07:34.340 --> 00:07:37.430
dependency down the chain. And,
there are specific and unique

141
00:07:37.430 --> 00:07:41.600
tools for doing that dependency
analysis across a piece of

142
00:07:41.630 --> 00:07:45.230
open-source software that gets
really challenging. So that just

143
00:07:45.230 --> 00:07:48.830
goes back to, kind of, that
staffing thing. Are you ready to

144
00:07:48.830 --> 00:07:51.860
staff up the people process and
technology to do this the right

145
00:07:51.860 --> 00:07:54.710
way? And that's, I think, a
really tough cost trade-off

146
00:07:54.710 --> 00:07:57.500
question that each organization
has to really tackle. But, I,

147
00:07:57.500 --> 00:08:00.650
kind of, want to kick it to
Chris as well, when it comes to,

148
00:08:00.650 --> 00:08:03.530
kind of, the customers he's
serving and the clients he's

149
00:08:03.530 --> 00:08:06.530
serving. What are you seeing out
there in terms of consuming

150
00:08:06.620 --> 00:08:08.210
open-source or freeware
software?

151
00:08:08.840 --> 00:08:10.730
Chris Hughes: Yeah, I think, in
many organizations, like you

152
00:08:10.730 --> 00:08:13.520
talked about, it's not necessary
that using open-source software

153
00:08:13.520 --> 00:08:16.370
is inherently bad. It's just
that many organizations that are

154
00:08:16.370 --> 00:08:19.040
using it simply don't have a
good inventory of what they're

155
00:08:19.040 --> 00:08:21.260
using. When we think about
critical security controls,

156
00:08:21.260 --> 00:08:24.110
software asset inventory has
been a critical control for, you

157
00:08:24.110 --> 00:08:26.600
know, decades. And, many
organizations just don't have a

158
00:08:26.600 --> 00:08:29.060
good understanding of what
open-source software they're

159
00:08:29.060 --> 00:08:31.970
using, whether internally
developed software or that

160
00:08:31.970 --> 00:08:34.190
they're consuming from third
parties that they, you know, a

161
00:08:34.190 --> 00:08:38.090
lot of proprietary vendors are
also using open-source software

162
00:08:38.090 --> 00:08:41.570
extensively as well. And, as we
talked about, it's great to have

163
00:08:41.570 --> 00:08:44.840
that transparency factor of, you
know... There's a saying that

164
00:08:44.840 --> 00:08:47.810
underneath enough eyeballs all
bugs are shallow. And, that's,

165
00:08:47.810 --> 00:08:49.850
kind of, the pitch that you hear
for open-source. But, the

166
00:08:49.850 --> 00:08:52.310
reality is, when you look at the
maintenance of the open-source

167
00:08:52.310 --> 00:08:55.250
software ecosystem, some of the
metrics are downright alarming.

168
00:08:55.670 --> 00:08:58.520
Some of the metrics I've been
able to find are that 25% of

169
00:08:58.520 --> 00:09:02.060
projects in the open-source
ecosystem have one single

170
00:09:02.060 --> 00:09:05.690
maintainer contributing code to
it, 94% of them have less than

171
00:09:05.690 --> 00:09:08.210
10. So, when you're looking at
eyeballs, that's not a lot of

172
00:09:08.210 --> 00:09:11.660
eyeballs, obviously, to keep an
eye on these projects. And, then

173
00:09:11.660 --> 00:09:14.420
you have issues like he talked
about, in terms of getting

174
00:09:14.420 --> 00:09:16.820
timely updates. When we look at
the software, you know, in terms

175
00:09:16.820 --> 00:09:18.770
of updates, when you have a
proprietary piece of software,

176
00:09:18.770 --> 00:09:21.110
you have service-level
agreements, and things around

177
00:09:21.110 --> 00:09:23.540
getting updates or vulnerability
for mediating a certain

178
00:09:23.540 --> 00:09:26.150
timeline. With open-source
software, that's not the case.

179
00:09:26.150 --> 00:09:28.310
These are not your suppliers.
These are people doing this on

180
00:09:28.310 --> 00:09:30.980
their own free will and their
own free time. They owe you

181
00:09:30.980 --> 00:09:34.730
nothing. It's free to use as is
and you take it as is, for

182
00:09:34.730 --> 00:09:37.460
better or worse. So, many
organizations are simply

183
00:09:37.460 --> 00:09:40.460
struggling with that reality as
they look across their

184
00:09:40.460 --> 00:09:42.680
environment, their ecosystem and
see how widely they're using

185
00:09:42.710 --> 00:09:46.250
open-source software. And, the
growth has been tremendous, but

186
00:09:46.250 --> 00:09:49.790
our approach to security hasn't
simply scaled at the same time

187
00:09:50.030 --> 00:09:52.010
of our open-source software
adoption has.

188
00:09:53.240 --> 00:09:53.570
Tom Field: Well said!

189
00:09:53.570 --> 00:09:55.760
Mike Baker: I, kind of, want to
jump in on that too. Sorry, Tom.

190
00:09:55.910 --> 00:09:56.360
Tom Field: Yeah, go ahead!

191
00:09:56.720 --> 00:10:00.050
Mike Baker: You... Chris brought
up a great point that I really

192
00:10:00.050 --> 00:10:04.670
want to bring up was, the
licensing is so different, so

193
00:10:04.670 --> 00:10:07.880
varied; where it can be so
unique. So, we talked about all

194
00:10:07.880 --> 00:10:10.910
the investments you, maybe, need
to do the stuff. But, like, when

195
00:10:10.910 --> 00:10:13.430
you're looking at the uniqueness
of that licensing and the

196
00:10:13.430 --> 00:10:16.550
investment and the proper legal
expertise to look at that

197
00:10:16.550 --> 00:10:19.640
licensing and understand if your
usage is appropriate, given

198
00:10:19.640 --> 00:10:24.710
that, is super huge in this
world. And then, Chris also

199
00:10:24.710 --> 00:10:28.100
brought inventory, which I think
is really special. Inventory is

200
00:10:28.100 --> 00:10:32.270
hard enough, just seeng what you
have, right? You know, it really

201
00:10:32.270 --> 00:10:35.990
is. But, when you think about
using this level of software,

202
00:10:35.990 --> 00:10:39.530
those specialized skill sets and
inventory tools to go that one

203
00:10:39.530 --> 00:10:42.110
layer down to what we talked
about those dependencies within

204
00:10:42.110 --> 00:10:45.230
that software across the board,
right? So, transparency is

205
00:10:45.230 --> 00:10:48.110
great, but it adds a significant
amount of complexity into

206
00:10:48.110 --> 00:10:51.680
tracking that and maintaining
that particularly at scale. And,

207
00:10:51.950 --> 00:10:54.800
you really scared me with the
"community strength" comment,

208
00:10:54.800 --> 00:10:58.610
Chris. Saying the one person for
x, you know, 50%, or whatever of

209
00:10:58.610 --> 00:11:01.070
the projects, right? Because we
had talked about it. If you

210
00:11:01.070 --> 00:11:04.010
don't have the community
strength behind these, this

211
00:11:04.010 --> 00:11:09.230
software, is it appropriate for
enterprise use? No, I would

212
00:11:09.260 --> 00:11:12.680
hazard that the answer to that
question is likely, no, right?

213
00:11:12.680 --> 00:11:16.910
So, how are you assessing that
community, right? How are you

214
00:11:16.910 --> 00:11:20.510
assessing that developer? You
know, the backbone behind it?

215
00:11:20.870 --> 00:11:24.110
The supportability behind it? I
mean, absolutely huge questions

216
00:11:24.110 --> 00:11:26.690
that lead me away from using
this sort of software.

217
00:11:27.170 --> 00:11:30.710
Chris Hughes: Yeah, just to
piggyback Mike's comment there.

218
00:11:30.710 --> 00:11:33.440
Sonatype actually released their
state of software supply chain

219
00:11:33.620 --> 00:11:37.580
report for 2023, recently, and
they found that 11% of the

220
00:11:37.580 --> 00:11:40.340
projects they assessed are
actually actively maintained of

221
00:11:40.340 --> 00:11:43.940
the entire open-source software
ecosystem - 11%! So, it's

222
00:11:43.940 --> 00:11:46.970
pretty, you know, daunting to
think how many projects are

223
00:11:46.970 --> 00:11:49.550
simply not being maintained out
there but are still widely used.

224
00:11:50.720 --> 00:11:52.790
And, as he points out, like,
vulnerabilities are great, you

225
00:11:52.790 --> 00:11:56.060
know, but vulnerabilities are
also a lagging indicator of

226
00:11:56.060 --> 00:11:58.280
risk. It tells you, hey,
something's wrong, and we know

227
00:11:58.280 --> 00:12:00.230
what's wrong. But, guess what?
If you know what's wrong, so do

228
00:12:00.230 --> 00:12:02.810
malicious actors, they know
what's wrong as well. You need

229
00:12:02.810 --> 00:12:05.030
to be looking at other things
like project health, and you

230
00:12:05.030 --> 00:12:07.280
know, the vitality of the
project, you know, what kind of

231
00:12:07.280 --> 00:12:08.900
protections they have in place,
and so on.

232
00:12:10.490 --> 00:12:12.440
Tom Field: It's funny, you
mentioned Sonatype. I like to

233
00:12:12.440 --> 00:12:16.010
speak with Brian Fox, the CTO
and co-founder. And, our ongoing

234
00:12:16.010 --> 00:12:18.650
joke is when I see him, as I
say, "Brian, what's the state of

235
00:12:18.650 --> 00:12:21.950
software supply chain security
today?" And, it ranges from

236
00:12:21.950 --> 00:12:25.550
embarrassing to unacceptable to
whatever explanation he can put

237
00:12:25.550 --> 00:12:28.880
in there. But, very consistent
with what you say, Chris, I

238
00:12:28.880 --> 00:12:31.220
appreciate your insight here.
Michael, one last question for

239
00:12:31.220 --> 00:12:33.620
you. I'm going to turn this back
to Anna and to Chris, we've

240
00:12:33.620 --> 00:12:36.890
talked about a lot in just a few
minutes here. How are you at DXC

241
00:12:36.920 --> 00:12:39.920
addressing the issue of
unmaintained open-source

242
00:12:39.920 --> 00:12:42.770
software and all the potential
security risks we've discussed?

243
00:12:43.220 --> 00:12:44.990
Mike Baker: So, I know, I'm not
going to talk about how we're

244
00:12:44.990 --> 00:12:47.090
doing at our company
specifically, right? But, I

245
00:12:47.090 --> 00:12:52.490
think, in general, it's pretty
easy. It goes back to policy and

246
00:12:52.490 --> 00:12:56.840
process, right? We've talked
about the necessity to have an

247
00:12:56.870 --> 00:13:01.310
enterprise-wide view on what the
software is, have that policy,

248
00:13:01.310 --> 00:13:04.820
communicate that policy, educate
users, particularly, in a wide

249
00:13:04.820 --> 00:13:08.300
scale, in terms of what is the
appropriate use of this? When

250
00:13:08.300 --> 00:13:11.330
you look at that, and you look
at the process? Are we going to

251
00:13:11.330 --> 00:13:14.210
have the process in place to vet
this, to look at the communities

252
00:13:14.210 --> 00:13:17.690
we mentioned, to hire the people
and the expertise needed to run

253
00:13:17.690 --> 00:13:21.260
that process effectively? But, I
think it goes back to, kind of,

254
00:13:21.260 --> 00:13:25.460
the basics, right? What's the
usage of this? What do we use

255
00:13:25.460 --> 00:13:28.790
them for? Right? So, when you
look at data sensitivity,

256
00:13:28.910 --> 00:13:33.500
business criticality, these are
cornerstones of any third-party

257
00:13:33.500 --> 00:13:36.470
risk management program or
software supply chain program,

258
00:13:36.500 --> 00:13:39.740
right? So, how are we doing the
basics right? Do we know what

259
00:13:39.740 --> 00:13:42.710
data will be consumed or
manipulated by this piece of

260
00:13:42.710 --> 00:13:46.160
software, right? Do we know the
business criticality or the

261
00:13:46.190 --> 00:13:50.240
RTOs/RPOs? Are we asking those
questions and then giving that

262
00:13:50.300 --> 00:13:52.850
to the people and the analysts
that have the expertise to

263
00:13:52.850 --> 00:13:56.390
actually do open-source rather
than just generic sort of

264
00:13:56.420 --> 00:13:59.810
third-party risk management?
This is way beyond the world of

265
00:13:59.870 --> 00:14:02.480
questionnaires being sent out.
You can't send a questionnaire,

266
00:14:02.480 --> 00:14:05.720
right? Nor are they obligated to
answer it, right? So, we just

267
00:14:05.720 --> 00:14:09.080
make sure we have to staff it.
We have to get the policy, the

268
00:14:09.080 --> 00:14:13.520
vetted policy, across the board,
a good process that works, and

269
00:14:13.520 --> 00:14:16.550
really do the basics right
around business criticality and

270
00:14:16.550 --> 00:14:17.540
data sensitivity.

271
00:14:17.990 --> 00:14:20.660
Tom Field: So Mike, thank you so
much, Anna, back to you and

272
00:14:20.660 --> 00:14:21.050
Chris.

273
00:14:21.620 --> 00:14:24.200
Anna Delaney: Excellent! This is
absolutely brilliant. So, Chris,

274
00:14:24.200 --> 00:14:26.540
I didn't do a formal
introduction earlier. So I'm

275
00:14:26.540 --> 00:14:29.270
just going to slot it in now.
You are Chris Hughes, of course,

276
00:14:29.360 --> 00:14:32.450
you write prolifically on the
topic of software supply chain

277
00:14:32.450 --> 00:14:36.440
security, co-founder and CISO at
Aquia. So, great to have you

278
00:14:36.440 --> 00:14:39.890
here. Following on from Mike's
last answer. What are some

279
00:14:39.950 --> 00:14:43.700
common misconceptions or
expectations that organizations

280
00:14:43.700 --> 00:14:46.100
have when it comes to
open-source software

281
00:14:46.100 --> 00:14:49.070
maintainers? And, how can these
be better understood and

282
00:14:49.070 --> 00:14:49.640
managed?

283
00:14:50.260 --> 00:14:52.180
Chris Hughes: Yeah, I think some
of the most common

284
00:14:52.480 --> 00:14:54.580
misperceptions - and you touched
on these a little bit to some

285
00:14:54.580 --> 00:14:57.370
extent - is, you know, it's,
kind of, a public good. And,

286
00:14:57.370 --> 00:14:59.740
people assume that, you know,
they can just continue to use it

287
00:14:59.740 --> 00:15:02.710
and it's inexhaustible. But, the
reality is that these projects

288
00:15:02.710 --> 00:15:05.620
are being maintained by a small
group of individuals that are

289
00:15:05.620 --> 00:15:09.430
doing it in their own free will.
And, they don't owe you

290
00:15:09.430 --> 00:15:11.590
anything. If there's a
vulnerability, they don't have

291
00:15:11.590 --> 00:15:15.070
to fix it, if there's a bug or a
defect, they have no timeline

292
00:15:15.070 --> 00:15:16.930
that they have to adhere to,
like a proprietary software

293
00:15:16.930 --> 00:15:19.960
vendor does, for example. So,
you can't send them a security

294
00:15:19.960 --> 00:15:22.780
questionnaire, you can't make
demands of them to fix defects

295
00:15:22.780 --> 00:15:25.030
or bugs or vulnerabilities. It
doesn't mean they won't. There's

296
00:15:25.030 --> 00:15:28.300
lots thriving, you know, robust
open-source software projects

297
00:15:28.300 --> 00:15:31.330
that have tremendous support
from people in the community.

298
00:15:31.330 --> 00:15:34.450
They're very responsive, and on
top of things, you know, on par

299
00:15:34.450 --> 00:15:37.930
with some of the best technology
leaders in the industry. But, on

300
00:15:37.930 --> 00:15:39.880
the other hand, there's a lot of
open-source software projects

301
00:15:39.880 --> 00:15:44.650
and components that are simply
not well-maintained and kept up,

302
00:15:44.650 --> 00:15:49.270
I should say. And then another
big misperception is that people

303
00:15:49.270 --> 00:15:51.250
don't have an understanding of
what they're even using. And,

304
00:15:51.250 --> 00:15:53.830
then they often look at their,
you know, direct dependencies,

305
00:15:53.830 --> 00:15:56.320
for example, but studies are
starting to show that, you know,

306
00:15:56.320 --> 00:15:58.990
most vulnerabilities are
actually coming from ... six out

307
00:15:58.990 --> 00:16:01.510
of seven vulnerabilities are
from transitive dependencies.

308
00:16:01.690 --> 00:16:04.390
So, we think about the supply
chain, you know, we see how it's

309
00:16:04.390 --> 00:16:06.820
a supplier of target who got
breached, who caused the target

310
00:16:06.820 --> 00:16:09.340
to get breached, kind of thing.
It's a dependency of your

311
00:16:09.340 --> 00:16:11.800
dependency that gets
compromised, that causes you to

312
00:16:12.370 --> 00:16:16.210
essentially be exploited or be
vulnerable, for example, so many

313
00:16:16.690 --> 00:16:19.150
organizations just don't have a
good understanding of the direct

314
00:16:19.150 --> 00:16:21.520
dependencies, let alone the
transitive dependencies and,

315
00:16:21.520 --> 00:16:24.430
kind of, sprawl of, you know,
how that, kind of, spreads out

316
00:16:24.430 --> 00:16:26.740
and the vulnerabilities that can
come back to impact them from

317
00:16:26.740 --> 00:16:28.090
that dependency tree.

318
00:16:29.020 --> 00:16:30.970
Anna Delaney: So, as you say,
given that six out of seven

319
00:16:30.970 --> 00:16:33.700
vulnerabilities come from
transitive dependencies, what

320
00:16:33.700 --> 00:16:36.730
are some strategies, or even
best practices, organizations

321
00:16:36.730 --> 00:16:40.240
can implement to manage and
secure transitive dependencies

322
00:16:40.240 --> 00:16:40.870
effectively?

323
00:16:41.350 --> 00:16:42.520
Chris Hughes: Yeah, I think,
starting to look at the

324
00:16:42.520 --> 00:16:44.620
ecosystem, we're seeing some
innovative vendors, you know,

325
00:16:44.620 --> 00:16:47.110
they're coming out, there's been
software composition analysis

326
00:16:47.110 --> 00:16:49.630
tools, and things like that for
quite a while. But, we're

327
00:16:49.630 --> 00:16:51.670
starting to see some more
innovative vendors come out with

328
00:16:51.730 --> 00:16:54.280
more modernized tooling that
can, kind of, help map out that

329
00:16:54.280 --> 00:16:57.130
dependency trees for you, not
just direct, but also transitive

330
00:16:57.130 --> 00:17:00.160
dependencies. And, then provide
critical insight. We've seen a

331
00:17:00.160 --> 00:17:02.470
lot of like, shift left, like,
you know, Tom used that term

332
00:17:02.470 --> 00:17:04.930
earlier, and we've seen the
industry try to push for shift

333
00:17:04.930 --> 00:17:08.770
left. But, the problem is a lot
of these tools, these SCA, SaaS,

334
00:17:08.770 --> 00:17:11.950
TaaS, etc. tooling, produce a
lot of noise. So, it's one thing

335
00:17:11.950 --> 00:17:13.720
to know that I have a
vulnerability, but is it

336
00:17:13.720 --> 00:17:16.420
actually reachable? Is it
exploitable? Should I be

337
00:17:16.420 --> 00:17:19.300
concerned with it? Because, if I
send a developer, you know, a

338
00:17:19.300 --> 00:17:23.800
report with 678 vulnerability
findings, I tell them, hey, this

339
00:17:23.800 --> 00:17:26.290
has to be addressed before you
go to production. I'm not making

340
00:17:26.290 --> 00:17:28.270
friends, and I'm not breaking
down silos, I'm actually

341
00:17:28.270 --> 00:17:30.940
building up resentment and
they're not going to want to

342
00:17:30.940 --> 00:17:33.640
engage with me. So, we're
starting to see some innovative

343
00:17:33.640 --> 00:17:37.270
SCA vendors, for example,
provide things like reachability

344
00:17:37.270 --> 00:17:40.960
for these transitive
dependencies. Is it vulnerable?

345
00:17:40.960 --> 00:17:43.300
And is it reachable on my code?
For example, is it actually

346
00:17:43.300 --> 00:17:46.480
used? Is it called as part of
the application, and then

347
00:17:46.480 --> 00:17:48.910
there's some great, you know,
kind of, industry-led efforts

348
00:17:48.910 --> 00:17:51.130
that are being led that are
available to anyone, you know, a

349
00:17:51.130 --> 00:17:53.380
couple of things I want to call
out is going to be CISA's Known

350
00:17:53.380 --> 00:17:56.230
Exploited Vulnerabilities
Catalog that's going to show you

351
00:17:56.260 --> 00:17:58.780
not only is something
vulnerable, but it is actually

352
00:17:58.780 --> 00:18:01.000
known to show exploiting in the
wild? Should I be concerned with

353
00:18:01.000 --> 00:18:03.340
this? Are malicious actors
actually targeting it right now?

354
00:18:03.760 --> 00:18:06.850
And then, also the EPSS, the
exploit prediction scoring

355
00:18:06.850 --> 00:18:09.670
system, that's another great
one. It's going to show you...

356
00:18:09.820 --> 00:18:12.280
they use a machine learning
model to, kind of, come up with

357
00:18:12.280 --> 00:18:15.490
figures around, you know, is
this vulnerability, this CVE,

358
00:18:15.670 --> 00:18:18.640
likely to be exploited in the
next 30 days? And, they've been

359
00:18:18.640 --> 00:18:21.310
incredibly accurate as they keep
iterating on this model. And,

360
00:18:21.340 --> 00:18:23.500
you know, it can help
prioritize, if I show something

361
00:18:23.530 --> 00:18:25.240
to a developer, I want to show
them, is it known to be

362
00:18:25.240 --> 00:18:28.060
exploited? Is it reachable? Is
it likely to be exploited?

363
00:18:28.630 --> 00:18:31.360
Because vulnerability backlog
some studies are showing are in

364
00:18:31.360 --> 00:18:33.850
the hundreds of thousands, even
1.1 million in some

365
00:18:33.880 --> 00:18:36.820
organizations and large
enterprises. So, we need some

366
00:18:36.820 --> 00:18:40.060
prioritization strategy here,
we're just going to drown people

367
00:18:40.240 --> 00:18:42.970
in reports with, you know, too
much information, they can't act

368
00:18:42.970 --> 00:18:43.270
on it.

369
00:18:44.410 --> 00:18:46.840
Mike Baker: And that, that
brings up the issue too, right,

370
00:18:46.840 --> 00:18:51.190
which is, you know, like, you
mentioned, the ability to pivot

371
00:18:51.220 --> 00:18:54.100
if the community support goes
away, or they're not doing

372
00:18:54.100 --> 00:18:57.010
something, how quickly can you
pivot? That application of

373
00:18:57.010 --> 00:19:00.250
application used for something
else? Or, can you plug that

374
00:19:00.250 --> 00:19:03.370
developer gap with people within
your own organization? Are they

375
00:19:03.370 --> 00:19:06.190
trained enough on what this
piece of software is? And then,

376
00:19:06.190 --> 00:19:10.750
you talked about the continuing
emerging nature of the vendors

377
00:19:10.750 --> 00:19:13.990
in this space, which does give
me pause, like, you know,

378
00:19:13.990 --> 00:19:17.380
someone who has to run the
program, Chris, it's like to me,

379
00:19:17.410 --> 00:19:20.350
yes, it's cool, it's innovative,
and will we get there

380
00:19:20.350 --> 00:19:25.150
eventually? Sure! Will we get
those dependencies chains

381
00:19:25.150 --> 00:19:29.440
cracked, at some point? Sure.
But, that's a lot to put on

382
00:19:29.440 --> 00:19:32.770
something that's critical to a
business or have any sort of

383
00:19:32.770 --> 00:19:37.210
scale, right? To your point.
Vulnerability management for

384
00:19:37.210 --> 00:19:40.120
off-the-shelf and supported
software through traditional

385
00:19:40.120 --> 00:19:43.480
vendors is hard enough. You add
this layer on top of it, you're

386
00:19:43.480 --> 00:19:45.910
really going to talk about
scaling the team and the cost

387
00:19:45.910 --> 00:19:46.930
associated with the program.

388
00:19:48.190 --> 00:19:49.780
Chris Hughes: Yeah, no doubt
about this. There's additional

389
00:19:49.840 --> 00:19:52.300
resource constraints. I feel
like, for a long time, like, you

390
00:19:52.300 --> 00:19:55.180
know, Tom made the joke what's
wrong with using software from

391
00:19:55.180 --> 00:19:57.610
strangers on the internet? For a
long time, that's the kind of

392
00:19:57.610 --> 00:20:00.040
perspective we've had, we've
just, kind of, used it without

393
00:20:00.040 --> 00:20:02.380
asking any questions. Now we're
seeing malicious actors target

394
00:20:02.380 --> 00:20:04.870
these while they use open-source
software projects and

395
00:20:04.870 --> 00:20:07.240
components. And, now we're, kind
of, pulling the curtain back and

396
00:20:07.270 --> 00:20:09.670
like, wow, we have a lot of
things we need to be concerned

397
00:20:09.670 --> 00:20:12.640
with and start paying attention
to, which, of course, as, you

398
00:20:12.640 --> 00:20:15.130
know, Mike points out, demand
resources, and we're already

399
00:20:15.130 --> 00:20:17.440
resource constrained when it
comes to talent in the workforce

400
00:20:17.440 --> 00:20:18.220
and things like that.

401
00:20:18.490 --> 00:20:21.520
Mike Baker: But, at the same
time, right, you have that

402
00:20:21.520 --> 00:20:24.610
philosophical question of the
transparency of the software as

403
00:20:24.610 --> 00:20:30.640
opposed to the same supply chain
threat, or risk that exists with

404
00:20:30.970 --> 00:20:35.140
off-the-shelf or enclosed
software. So, I know we can go

405
00:20:35.140 --> 00:20:37.810
either way on it, right?
Everything's a cost trade off.

406
00:20:37.810 --> 00:20:41.500
But, it's a very interesting
question, really, to back up in

407
00:20:41.500 --> 00:20:44.980
terms of that risk, and then,
you know, the actual support you

408
00:20:44.980 --> 00:20:49.660
need from a non-open-source
vendor is starting to be the

409
00:20:49.660 --> 00:20:52.390
exact same support you need from
an open-source vendor, right?

410
00:20:52.390 --> 00:20:54.640
You need to know the
dependencies and the bill of

411
00:20:54.640 --> 00:20:57.820
materials. And then, you know,
along with the existing

412
00:20:57.820 --> 00:21:00.190
supportability, and stuff like
that. So, it's just interesting

413
00:21:00.190 --> 00:21:03.730
how these worlds are merging
together after things like

414
00:21:03.730 --> 00:21:05.680
SolarWinds and other issues
we've seen lately.

415
00:21:05.800 --> 00:21:08.530
Chris Hughes: Yeah, just a last
comment on that, to add on to

416
00:21:08.530 --> 00:21:10.330
what Mike says, not that
open-source software is

417
00:21:10.330 --> 00:21:14.020
inherently bad, or inherently
more risky than proprietary

418
00:21:14.020 --> 00:21:16.630
software. This year, we've seen
breaches from Okta and

419
00:21:16.630 --> 00:21:19.480
Microsoft, and, you know, some
of the most leading capable

420
00:21:19.480 --> 00:21:22.000
technology vendors in the
ecosystem. It's just that

421
00:21:22.030 --> 00:21:24.220
malicious actors are
increasingly targeting software

422
00:21:24.220 --> 00:21:26.320
supply chain entities, whether
it's proprietary software

423
00:21:26.320 --> 00:21:30.040
vendors, open-source software
projects, nothing is infallible

424
00:21:30.040 --> 00:21:32.440
or, kind of, protected from this
threat, basically.

425
00:21:33.730 --> 00:21:35.380
Anna Delaney: And just, sorry.

426
00:21:35.000 --> 00:21:37.970
Mike Baker: We have to prepare
now, right? So, I mean, that's

427
00:21:37.970 --> 00:21:42.290
the thing. You know, we've, kind
of, logically got ourselves back

428
00:21:42.290 --> 00:21:45.710
to the same place. What I think
any company, at any point in

429
00:21:45.710 --> 00:21:48.860
time right now, needs is to
start staffing. A software

430
00:21:48.860 --> 00:21:52.460
supply chain or software supply
chain risk, regardless of

431
00:21:52.490 --> 00:21:56.960
open-source or off-the-shelf,
they really need to double down

432
00:21:56.960 --> 00:22:00.230
in terms of their focus from a
people in process side on this

433
00:22:00.230 --> 00:22:02.600
holistically across the board,
because it's not going away.

434
00:22:02.000 --> 00:22:06.800
Anna Delaney: That was
brilliant! Just to add, you

435
00:22:06.800 --> 00:22:10.670
know, you mentioned, Chris, new
technologies, new vendors, are

436
00:22:10.670 --> 00:22:14.270
there any specific tools that
you recommend for organizations

437
00:22:14.270 --> 00:22:16.940
to enhance their open-source
governance?

438
00:22:17.710 --> 00:22:19.510
Chris Hughes: Yeah, I don't want
to necessarily name any vendors,

439
00:22:19.510 --> 00:22:22.390
because I'll come across biased,
but as I talked about, like look

440
00:22:22.390 --> 00:22:25.300
at things like software
composition analysis, tools, a

441
00:22:25.300 --> 00:22:27.400
particularly newer, more
innovative vendors that are,

442
00:22:27.400 --> 00:22:29.740
kind of, adding these
capabilities around reachability

443
00:22:29.740 --> 00:22:32.530
or known exploitation, or are
likely to be exploited to

444
00:22:33.760 --> 00:22:36.610
vulnerabilities, for example.
And then, also look at some of

445
00:22:36.610 --> 00:22:38.740
the emerging SBOM vendors who
are just trying to help bring

446
00:22:38.740 --> 00:22:41.380
transparency. Like Mike said, we
have a long way to go with SBOM,

447
00:22:41.380 --> 00:22:45.460
we're not there quite a ways to
go. But, are your vendors even

448
00:22:45.460 --> 00:22:47.320
talking about this? Are they
willing to provide these

449
00:22:47.320 --> 00:22:50.350
artifacts or provide that level
of transparency. And then on the

450
00:22:50.350 --> 00:22:52.870
flip side, you have tools that
can help you ingest and start to

451
00:22:52.870 --> 00:22:54.820
reason about some of the things
that are in the software you're

452
00:22:54.820 --> 00:22:57.610
consuming and using. There's
some open-source tools out there

453
00:22:57.610 --> 00:23:01.180
as well as proprietary tools.
So, definitely take a look at,

454
00:23:01.180 --> 00:23:03.850
you know, SBOM tooling, software
composition analysis tooling,

455
00:23:03.940 --> 00:23:05.920
especially more newer,
innovative ones with

456
00:23:05.920 --> 00:23:09.160
reachability analysis and things
like that, you can just start to

457
00:23:09.160 --> 00:23:11.320
peel back the curtain and get an
idea of, you know, what you're

458
00:23:11.320 --> 00:23:13.480
up against and what your posture
looks like.

459
00:23:14.270 --> 00:23:16.040
Anna Delaney: Very helpful,
indeed. Okay. We appreciate

460
00:23:16.040 --> 00:23:20.720
that, Chris. And let's all come
together for a final question.

461
00:23:20.750 --> 00:23:22.730
And, hopefully answers from you.
Over to you, Tom.

462
00:23:23.090 --> 00:23:25.310
Tom Field: Excellent. Mike,
Chris, for both of you. Given

463
00:23:25.310 --> 00:23:27.350
everything we've talked about
here over the past 20 minutes or

464
00:23:27.350 --> 00:23:30.980
so how can organizations today
strike a balance - a critical

465
00:23:30.980 --> 00:23:34.400
balance - between leveraging the
advantages of open-source

466
00:23:34.430 --> 00:23:38.690
software and mitigating the
risks effectively? Mike?

467
00:23:40.550 --> 00:23:42.140
Mike Baker: Yeah, I mean, I
think we've talked about it

468
00:23:42.170 --> 00:23:45.980
right, going into it eyes wide
open, right? There's advantages,

469
00:23:46.010 --> 00:23:48.770
like I mentioned, cost,
flexibility, transparency,

470
00:23:48.950 --> 00:23:52.250
voting vendor lock-in. But,
there's other significant costs

471
00:23:52.250 --> 00:23:54.890
associated with setting up the
right people, processes and

472
00:23:54.890 --> 00:23:58.940
technologies. And really, you
know, is it a risk acceptance

473
00:23:58.940 --> 00:24:02.420
sort of thing, right? Or, is it
something that you're going to

474
00:24:02.420 --> 00:24:06.680
apply slowly across non-mission
critical sort of applications or

475
00:24:06.680 --> 00:24:10.040
uses? So, I think, going into it
eyes wide open and no, it's not

476
00:24:10.040 --> 00:24:13.520
like the panacea. And, this is
something that organizations

477
00:24:13.520 --> 00:24:17.300
need to prioritize starting now,
right across all of their

478
00:24:17.300 --> 00:24:21.050
software, not just open-source,
in terms of understanding what

479
00:24:21.050 --> 00:24:23.210
their third-party risk
management program looks like.

480
00:24:23.270 --> 00:24:26.570
Is it accounting for software
supply chain risk? And, how are

481
00:24:26.570 --> 00:24:28.610
they keeping up with the
industry that's rapidly

482
00:24:28.610 --> 00:24:29.090
evolving?

483
00:24:30.260 --> 00:24:31.940
Chris Hughes: Yeah, and I'll
jump in and just build on that,

484
00:24:31.940 --> 00:24:34.460
you know, comment from Mike. I
like a few things he said there.

485
00:24:34.460 --> 00:24:37.790
One is that there's no panacea.
There's no silver bullet. It is

486
00:24:37.790 --> 00:24:40.850
a journey. It's just a matter of
understanding where we are right

487
00:24:40.850 --> 00:24:43.460
now, when it comes to software
supply chain security, are we at

488
00:24:43.550 --> 00:24:45.770
least aware of the threat? You
know, are we aware of what our

489
00:24:45.770 --> 00:24:49.250
software suppliers look like?
And, what measures are we taking

490
00:24:49.250 --> 00:24:52.280
internally to put the people,
process and tooling in place to

491
00:24:52.280 --> 00:24:55.220
start to tackle this threat?
Just getting a sense of where

492
00:24:55.220 --> 00:24:58.340
you stand and start to do a gap
of where you want to be? And as

493
00:24:58.340 --> 00:25:00.350
he talked about, you know, kind
of, aligning with risk

494
00:25:00.350 --> 00:25:03.140
tolerance, it's not that we're
trying to eliminate all risk and

495
00:25:03.140 --> 00:25:05.780
anything is inherently
automatically bad. But, just

496
00:25:05.780 --> 00:25:07.580
understanding, you know, what
risks are we willing to

497
00:25:07.610 --> 00:25:09.560
tolerate? And, then what
protections and controls are we

498
00:25:09.560 --> 00:25:11.570
putting in place to mitigate the
risks that we aren't willing to

499
00:25:11.570 --> 00:25:12.080
accept?

500
00:25:13.190 --> 00:25:15.410
Tom Field: Well said! Anna, we
got to schedule a part three.

501
00:25:16.460 --> 00:25:19.880
Anna Delaney: We do! Software
liability. Isn't that it? Or,

502
00:25:19.880 --> 00:25:22.430
vendor liability? That's what
we're tackling. I look forward

503
00:25:22.430 --> 00:25:26.420
to that. Well, we really value
your insight, Chris and Mike,

504
00:25:26.420 --> 00:25:28.250
thank you so much. This has been
so useful.

505
00:25:29.810 --> 00:25:30.380
Chris Hughes: Thanks for having
us.

506
00:25:30.380 --> 00:25:31.220
Mike Baker: Thanks for having
us.

507
00:25:32.420 --> 00:25:34.190
Anna Delaney: And, thanks so
much for watching. Until next

508
00:25:34.190 --> 00:25:34.550
time.