WEBVTT

1
00:00:00.000 --> 00:00:01.350
In this lesson,

2
00:00:01.350 --> 00:00:04.200
we will learn about software assurance.

3
00:00:04.200 --> 00:00:07.950
Software assurance is the process of ensuring software

4
00:00:07.950 --> 00:00:10.890
is developed and maintained in a way

5
00:00:10.890 --> 00:00:15.240
that consistently meets security and reliability standards.

6
00:00:15.240 --> 00:00:18.090
This protects the software from vulnerabilities

7
00:00:18.090 --> 00:00:19.800
and malicious threats.

8
00:00:19.800 --> 00:00:22.230
Software assurance concepts include

9
00:00:22.230 --> 00:00:25.680
a Software Bill of Materials, or SBoM,

10
00:00:25.680 --> 00:00:29.760
Software Composition Analysis, or SCA,

11
00:00:29.760 --> 00:00:33.750
and formal methods of validating software correctness,

12
00:00:33.750 --> 00:00:35.700
safety, and security.

13
00:00:35.700 --> 00:00:40.700
First, we have a Software Bill of Materials, or SBoM.

14
00:00:40.740 --> 00:00:45.570
An SBoM is like a detailed ingredient list for software.

15
00:00:45.570 --> 00:00:49.800
Just as a food label shows all the ingredients in a product,

16
00:00:49.800 --> 00:00:54.800
an SBoM provides a clear breakdown of every component,

17
00:00:54.870 --> 00:00:59.520
library, and dependency used in a software application.

18
00:00:59.520 --> 00:01:02.940
This level of transparency is important

19
00:01:02.940 --> 00:01:06.960
because it helps developers and users understand

20
00:01:06.960 --> 00:01:08.850
what the software is made of.

21
00:01:08.850 --> 00:01:12.960
Each component in a software bill of materials, or SBoM,

22
00:01:12.960 --> 00:01:16.020
is identified by its name, version,

23
00:01:16.020 --> 00:01:20.550
and a unique identifier, such as a cryptographic hash.

24
00:01:20.550 --> 00:01:24.630
The identifier ensures the integrity of the software

25
00:01:24.630 --> 00:01:28.440
by verifying that no components have been altered.

26
00:01:28.440 --> 00:01:31.200
In addition to listing direct dependencies,

27
00:01:31.200 --> 00:01:35.400
such as libraries and modules explicitly called

28
00:01:35.400 --> 00:01:37.620
or imported by the software,

29
00:01:37.620 --> 00:01:41.520
the SBoM also tracks transitive dependencies.

30
00:01:41.520 --> 00:01:44.130
Transitive dependencies are the components

31
00:01:44.130 --> 00:01:46.980
that those direct dependencies rely on.

32
00:01:46.980 --> 00:01:51.980
For example, if the software directly depends on library A

33
00:01:52.140 --> 00:01:55.890
and library A depends on library B,

34
00:01:55.890 --> 00:02:00.180
then library B is considered a transitive dependency.

35
00:02:00.180 --> 00:02:03.090
Direct and transitive dependencies create

36
00:02:03.090 --> 00:02:07.665
a full dependency graph outlining every element involved

37
00:02:07.665 --> 00:02:08.910
in the software.

38
00:02:08.910 --> 00:02:12.570
This transparency is crucial for developers,

39
00:02:12.570 --> 00:02:16.260
cybersecurity teams, and users alike,

40
00:02:16.260 --> 00:02:18.360
as it provides insight

41
00:02:18.360 --> 00:02:21.510
into any known vulnerabilities associated

42
00:02:21.510 --> 00:02:25.500
with specific versions of libraries or dependencies.

43
00:02:25.500 --> 00:02:29.910
This allows for quick action when a security issue arises.

44
00:02:29.910 --> 00:02:32.910
The software bill of materials also ensures there

45
00:02:32.910 --> 00:02:34.980
are no hidden, outdated,

46
00:02:34.980 --> 00:02:38.610
or insecure components within the application,

47
00:02:38.610 --> 00:02:42.570
significantly improving the software's security posture

48
00:02:42.570 --> 00:02:45.210
and compliance with security standards.

49
00:02:45.210 --> 00:02:49.620
So, imagine you are developing a web application

50
00:02:49.620 --> 00:02:53.430
and you rely on open source libraries like React

51
00:02:53.430 --> 00:02:57.390
for the frontend, Express.js for the backend,

52
00:02:57.390 --> 00:02:59.940
and a MongoDB database.

53
00:02:59.940 --> 00:03:02.310
Your software bill of materials

54
00:03:02.310 --> 00:03:04.770
would list all of these components,

55
00:03:04.770 --> 00:03:07.800
along with the details about their versions

56
00:03:07.800 --> 00:03:10.470
and any dependencies they bring in.

57
00:03:10.470 --> 00:03:13.320
If a security vulnerability is then found

58
00:03:13.320 --> 00:03:15.930
in a specific version of React,

59
00:03:15.930 --> 00:03:17.580
you can quickly identify

60
00:03:17.580 --> 00:03:20.730
that your application uses that version

61
00:03:20.730 --> 00:03:24.360
and take immediate action to update or patch it.

62
00:03:24.360 --> 00:03:27.090
Without a Software Bill of Materials,

63
00:03:27.090 --> 00:03:30.210
quickly identifying this type of issue

64
00:03:30.210 --> 00:03:34.050
would be very time consuming and prone to oversight,

65
00:03:34.050 --> 00:03:38.220
putting your application and your users at risk.

66
00:03:38.220 --> 00:03:41.550
So, by using a software bill of materials,

67
00:03:41.550 --> 00:03:45.420
companies can proactively manage their software security,

68
00:03:45.420 --> 00:03:48.960
making it easier to track down and address issues

69
00:03:48.960 --> 00:03:51.480
before they become a problem.

70
00:03:51.480 --> 00:03:56.480
Second, we have Software Composition Analysis, or SCA.

71
00:03:57.150 --> 00:04:00.000
Now, whenever you or your vendors

72
00:04:00.000 --> 00:04:04.230
use third party dependencies or open source components,

73
00:04:04.230 --> 00:04:07.050
you are taking the responsibility not just

74
00:04:07.050 --> 00:04:08.670
for the code you wrote,

75
00:04:08.670 --> 00:04:11.520
but also for the code you didn't write,

76
00:04:11.520 --> 00:04:14.850
like the libraries and frameworks you import

77
00:04:14.850 --> 00:04:16.830
into your code base.

78
00:04:16.830 --> 00:04:19.080
To identify what libraries

79
00:04:19.080 --> 00:04:21.690
and components are in your software,

80
00:04:21.690 --> 00:04:24.210
even when you didn't write them,

81
00:04:24.210 --> 00:04:27.330
you can perform Software Composition Analysis.

82
00:04:27.330 --> 00:04:29.790
This involves scanning your software

83
00:04:29.790 --> 00:04:33.030
to find all the third party components

84
00:04:33.030 --> 00:04:36.180
and checking them for known vulnerabilities.

85
00:04:36.180 --> 00:04:39.690
Automated tools can make this process easier.

86
00:04:39.690 --> 00:04:44.010
For example, the Open Web Application Security Project,

87
00:04:44.010 --> 00:04:48.480
or OWASP Dependency-Check is a widely used tool

88
00:04:48.480 --> 00:04:51.840
that scans a project and its libraries

89
00:04:51.840 --> 00:04:56.190
to identify any publicly disclosed vulnerabilities.

90
00:04:56.190 --> 00:05:00.240
Another OWASP tool called Dependency-Track

91
00:05:00.240 --> 00:05:04.590
offers even deeper insights by continuously monitoring

92
00:05:04.590 --> 00:05:08.820
and analyzing the security of components within your code,

93
00:05:08.820 --> 00:05:13.410
allowing you to act quickly if a vulnerability is found.

94
00:05:13.410 --> 00:05:15.480
To put this into perspective,

95
00:05:15.480 --> 00:05:19.800
let's consider widely used frameworks like Apache Struts.

96
00:05:19.800 --> 00:05:23.700
Apache Struts did have an unpatched vulnerability,

97
00:05:23.700 --> 00:05:27.750
which played a significant role in the Equifax breach.

98
00:05:27.750 --> 00:05:32.640
The vulnerability CVE-2017-5638

99
00:05:32.640 --> 00:05:35.340
was within Apache Struts 2.

100
00:05:35.340 --> 00:05:39.270
Specifically, the flaw involved improper handling

101
00:05:39.270 --> 00:05:42.090
of file upload requests using

102
00:05:42.090 --> 00:05:44.880
the Jakarta Multipart Parser,

103
00:05:44.880 --> 00:05:49.560
it allowed attacker to execute remote code on the system.

104
00:05:49.560 --> 00:05:54.300
This incident highlights the risks of unpatched software,

105
00:05:54.300 --> 00:05:58.050
but Apache Struts is just one example.

106
00:05:58.050 --> 00:06:01.530
Other common frameworks like Microsoft.NET,

107
00:06:01.530 --> 00:06:04.920
Ruby on Rails, Hibernate for Java,

108
00:06:04.920 --> 00:06:08.880
and Django for Python also help developers

109
00:06:08.880 --> 00:06:13.290
by providing reusable code and simplifying development.

110
00:06:13.290 --> 00:06:15.780
However, by using these frameworks,

111
00:06:15.780 --> 00:06:20.160
organizations also inherit any potential vulnerabilities

112
00:06:20.160 --> 00:06:22.680
that exist in the reused code.

113
00:06:22.680 --> 00:06:26.340
Therefore, when new vulnerabilities are discovered,

114
00:06:26.340 --> 00:06:29.670
it's very important for organizations to track

115
00:06:29.670 --> 00:06:34.050
and patch these issues to maintain software security.

116
00:06:34.050 --> 00:06:38.970
Tools like Software Composition Analysis, or SCA,

117
00:06:38.970 --> 00:06:41.190
can help automate this process,

118
00:06:41.190 --> 00:06:45.000
ensuring that both direct and transitive dependencies

119
00:06:45.000 --> 00:06:47.250
are up to date and secure.

120
00:06:47.250 --> 00:06:52.250
Third and last, we have formal methods of validation.

121
00:06:52.290 --> 00:06:55.440
Formal methods of evaluation and validation

122
00:06:55.440 --> 00:06:59.700
for software assurance use mathematically based techniques

123
00:06:59.700 --> 00:07:04.230
to guarantee that software is free from errors, bugs,

124
00:07:04.230 --> 00:07:06.570
and security vulnerabilities.

125
00:07:06.570 --> 00:07:10.140
These methods go beyond traditional testing

126
00:07:10.140 --> 00:07:13.800
by mathematically proving that the software behaves

127
00:07:13.800 --> 00:07:17.670
as expected under all possible conditions.

128
00:07:17.670 --> 00:07:20.490
This approach is especially important

129
00:07:20.490 --> 00:07:24.600
for systems like aviation, healthcare, or finance,

130
00:07:24.600 --> 00:07:29.600
where even minor failures can have serious consequences.

131
00:07:29.610 --> 00:07:33.990
Model checking is a popular form of validation

132
00:07:33.990 --> 00:07:37.170
that involves creating a model of a system

133
00:07:37.170 --> 00:07:41.760
and rigorously verifying it against predefined rules.

134
00:07:41.760 --> 00:07:46.470
Tools like the Simple Promela Interceptor, or SPIN,

135
00:07:46.470 --> 00:07:49.410
are frequently used in distributed systems

136
00:07:49.410 --> 00:07:52.050
to ensure that every possible state

137
00:07:52.050 --> 00:07:54.660
and transition is explored,

138
00:07:54.660 --> 00:07:58.290
helping to identify issues such as deadlocks

139
00:07:58.290 --> 00:08:01.740
or safety violations that might be overlooked

140
00:08:01.740 --> 00:08:03.390
in standard testing.

141
00:08:03.390 --> 00:08:06.780
Another powerful technique is theorem proving

142
00:08:06.780 --> 00:08:10.650
where tools like C-O-Q, or Coq,

143
00:08:10.650 --> 00:08:14.100
and Isabelle generate formal proofs

144
00:08:14.100 --> 00:08:16.980
to verify the correctness of algorithms

145
00:08:16.980 --> 00:08:19.170
and software components.

146
00:08:19.170 --> 00:08:22.080
For example, Coq has been used

147
00:08:22.080 --> 00:08:25.770
to formally verify cryptographic algorithms,

148
00:08:25.770 --> 00:08:28.770
providing a mathematical guarantee

149
00:08:28.770 --> 00:08:32.880
that these algorithms meet their security requirements.

150
00:08:32.880 --> 00:08:37.290
Abstract interpretation is another validation technique.

151
00:08:37.290 --> 00:08:41.550
Abstract interpretation uses tools like Astree

152
00:08:41.550 --> 00:08:44.430
to analyze the software's behavior

153
00:08:44.430 --> 00:08:46.710
without actually running it.

154
00:08:46.710 --> 00:08:50.670
Astree was famously used in the aerospace industry

155
00:08:50.670 --> 00:08:55.260
to ensure the safety of Airbus flight control software.

156
00:08:55.260 --> 00:08:59.220
Checking for runtime errors like division by zero

157
00:08:59.220 --> 00:09:01.290
or buffer overflows.

158
00:09:01.290 --> 00:09:04.860
The abstract interpretation method helps ensure

159
00:09:04.860 --> 00:09:08.880
that software remains reliable under all conditions.

160
00:09:08.880 --> 00:09:13.530
To simplify our understanding of formal validation methods,

161
00:09:13.530 --> 00:09:16.920
let's consider a traffic light control system.

162
00:09:16.920 --> 00:09:18.810
By using formal methods,

163
00:09:18.810 --> 00:09:22.110
we could model how the traffic lights should change

164
00:09:22.110 --> 00:09:23.850
based on traffic flow,

165
00:09:23.850 --> 00:09:28.110
and then use a tool like the Simple Promela Interpreter

166
00:09:28.110 --> 00:09:30.810
to check every possible scenario.

167
00:09:30.810 --> 00:09:32.580
SPIN could then validate

168
00:09:32.580 --> 00:09:36.510
that no two directions get a green light at the same time,

169
00:09:36.510 --> 00:09:38.160
preventing accidents.

170
00:09:38.160 --> 00:09:40.200
In real-world software,

171
00:09:40.200 --> 00:09:44.790
these methods similarly help developers spot flaws

172
00:09:44.790 --> 00:09:47.340
and potential failures early on

173
00:09:47.340 --> 00:09:50.130
before they cause major issues.

174
00:09:50.130 --> 00:09:54.630
So, remember, software assurance is the process

175
00:09:54.630 --> 00:09:57.450
of making sure that software is built

176
00:09:57.450 --> 00:10:00.570
and maintained to meet high security

177
00:10:00.570 --> 00:10:02.790
and reliability standards.

178
00:10:02.790 --> 00:10:06.300
One important concept in software assurance

179
00:10:06.300 --> 00:10:09.900
is the Software Bill of Materials, or SBoM.

180
00:10:09.900 --> 00:10:14.430
An SBoM provides a detailed breakdown of all components,

181
00:10:14.430 --> 00:10:19.430
libraries, and dependencies used in a software application.

182
00:10:19.560 --> 00:10:24.150
This transparency helps identify any vulnerabilities

183
00:10:24.150 --> 00:10:26.760
in third party software components.

184
00:10:26.760 --> 00:10:30.780
Another key concept is Software Composition Analysis,

185
00:10:30.780 --> 00:10:34.620
or SCA, which involves scanning software

186
00:10:34.620 --> 00:10:38.070
to detect known vulnerabilities in the libraries

187
00:10:38.070 --> 00:10:40.386
and frameworks that are used.

188
00:10:40.386 --> 00:10:45.330
SCA tools include the OWASP Dependency-Check

189
00:10:45.330 --> 00:10:48.780
and the OWASP Dependency-Track.

190
00:10:48.780 --> 00:10:52.140
Finally, formal methods of validation

191
00:10:52.140 --> 00:10:55.920
use mathematical techniques like model checking

192
00:10:55.920 --> 00:10:58.650
and theorem proving to guarantee

193
00:10:58.650 --> 00:11:02.220
that software is free from bugs and vulnerabilities,

194
00:11:02.220 --> 00:11:06.540
ensuring it behaves as expected in all scenarios.

195
00:11:06.540 --> 00:11:11.280
These methods are particularly useful in critical systems

196
00:11:11.280 --> 00:11:15.210
where even small errors can lead to major issues,

197
00:11:15.210 --> 00:11:18.183
like in aviation or finance.