1 00:00:00,360 --> 00:00:01,200 In this lesson, 2 00:00:01,200 --> 00:00:04,500 we're going to discuss the world of application security. 3 00:00:04,500 --> 00:00:07,020 Application security is a critical aspect 4 00:00:07,020 --> 00:00:08,700 of software development that focuses 5 00:00:08,700 --> 00:00:11,910 on building applications that are secure by design. 6 00:00:11,910 --> 00:00:13,950 By utilizing application security, 7 00:00:13,950 --> 00:00:16,140 implement measures to prevent, detect, 8 00:00:16,140 --> 00:00:18,300 and remediate security vulnerabilities. 9 00:00:18,300 --> 00:00:20,430 There are six main areas we need to look at 10 00:00:20,430 --> 00:00:22,140 in terms of application security, 11 00:00:22,140 --> 00:00:25,110 including input validation, secure cookies, 12 00:00:25,110 --> 00:00:27,990 static code analysis, dynamic code analysis, 13 00:00:27,990 --> 00:00:30,780 code signing, and sandboxing. 14 00:00:30,780 --> 00:00:33,030 First, we have input validation. 15 00:00:33,030 --> 00:00:35,190 Input validation is a fundamental aspect 16 00:00:35,190 --> 00:00:38,160 of application security that acts as a gatekeeper 17 00:00:38,160 --> 00:00:39,900 to ensure that applications only act 18 00:00:39,900 --> 00:00:42,930 on well-defined and uncontaminated data. 19 00:00:42,930 --> 00:00:44,340 Input validation is focused 20 00:00:44,340 --> 00:00:47,160 on directly countering various forms of attacks 21 00:00:47,160 --> 00:00:49,770 aimed at exploiting data input vulnerabilities 22 00:00:49,770 --> 00:00:53,370 to preserve the integrity and behavior of the application. 23 00:00:53,370 --> 00:00:55,620 In the vast and complex world of software, 24 00:00:55,620 --> 00:00:58,380 where interactions are multifaceted and unlimited, 25 00:00:58,380 --> 00:01:00,510 the need to authenticate, clean, 26 00:01:00,510 --> 00:01:03,213 and secure data inputs cannot be overstated. 27 00:01:04,050 --> 00:01:06,510 Whether it's a user who fills out a form, 28 00:01:06,510 --> 00:01:09,120 data is transferred from one application to another, 29 00:01:09,120 --> 00:01:12,420 or an internal function calls another within a system, 30 00:01:12,420 --> 00:01:13,920 these are all considered inputs 31 00:01:13,920 --> 00:01:15,720 and must be properly validated 32 00:01:15,720 --> 00:01:18,360 before the application performs any kind of operation 33 00:01:18,360 --> 00:01:20,730 using the user-provided data. 34 00:01:20,730 --> 00:01:23,010 Each of these types of data being input 35 00:01:23,010 --> 00:01:24,990 will represent a point of interaction 36 00:01:24,990 --> 00:01:27,540 as well as potential vulnerability to our systems. 37 00:01:27,540 --> 00:01:30,930 Often, threat actors will attempt to break into a system 38 00:01:30,930 --> 00:01:32,940 by feeding it data that could trigger 39 00:01:32,940 --> 00:01:35,100 an unintended reaction or breach 40 00:01:35,100 --> 00:01:38,760 by conducting a SQL injection, cross-site scripting, 41 00:01:38,760 --> 00:01:41,940 buffer overflow, and other types of attacks. 42 00:01:41,940 --> 00:01:44,130 This is why input validation is important, 43 00:01:44,130 --> 00:01:46,920 because it serves as a kind of quality control for data 44 00:01:46,920 --> 00:01:48,600 to ensure that every piece of information 45 00:01:48,600 --> 00:01:51,000 is valid, secure, and correctly formatted 46 00:01:51,000 --> 00:01:53,100 before it's processed by the application. 47 00:01:53,100 --> 00:01:55,860 This is not just about preventing malicious attacks, 48 00:01:55,860 --> 00:01:57,750 but it also helps to ensure that our systems 49 00:01:57,750 --> 00:02:01,020 behave predictably and can handle errors gracefully. 50 00:02:01,020 --> 00:02:03,960 For example, if a function expects a numerical value 51 00:02:03,960 --> 00:02:05,490 but receives a string instead, 52 00:02:05,490 --> 00:02:07,950 it could cause errors or unpredictable behavior. 53 00:02:07,950 --> 00:02:10,530 Proper input validation catches such issues 54 00:02:10,530 --> 00:02:13,230 before the application attempts to perform an operation 55 00:02:13,230 --> 00:02:15,030 on the wrong type of data. 56 00:02:15,030 --> 00:02:16,560 Implementing input validation 57 00:02:16,560 --> 00:02:18,960 involves establishing specific criteria 58 00:02:18,960 --> 00:02:20,820 known as validation rules. 59 00:02:20,820 --> 00:02:25,110 These rules delineate acceptable and unacceptable inputs. 60 00:02:25,110 --> 00:02:26,640 For instance, if the input field 61 00:02:26,640 --> 00:02:28,320 is expecting a phone number, 62 00:02:28,320 --> 00:02:30,720 and the validation rules might require 10 digits 63 00:02:30,720 --> 00:02:34,080 and no letters, special characters, or additional digits. 64 00:02:34,080 --> 00:02:37,200 Anything outside of this would be flagged and rejected, 65 00:02:37,200 --> 00:02:38,820 or the system might request the user 66 00:02:38,820 --> 00:02:40,770 to input the data again. 67 00:02:40,770 --> 00:02:42,360 These rules can be very simple, 68 00:02:42,360 --> 00:02:44,490 like checking if input is empty, 69 00:02:44,490 --> 00:02:47,310 or more complex, like verifying if the input 70 00:02:47,310 --> 00:02:50,223 matches a regular expression used by an email address. 71 00:02:51,090 --> 00:02:52,807 However, input validation is not just 72 00:02:52,807 --> 00:02:54,570 about setting up boundaries, 73 00:02:54,570 --> 00:02:57,090 but it's also an important security measure 74 00:02:57,090 --> 00:03:00,570 to ensure that data is validated early in the process. 75 00:03:00,570 --> 00:03:02,700 We refer to this as front-end validation, 76 00:03:02,700 --> 00:03:04,980 where any web forms created in an application 77 00:03:04,980 --> 00:03:07,380 will ensure that the data matches the right format 78 00:03:07,380 --> 00:03:08,820 before accepting it. 79 00:03:08,820 --> 00:03:10,710 Conversely, we will also implement 80 00:03:10,710 --> 00:03:12,420 back-end validation as well 81 00:03:12,420 --> 00:03:14,310 to ensure that our servers check the data 82 00:03:14,310 --> 00:03:17,270 prior to allowing an application to utilize that data. 83 00:03:17,270 --> 00:03:19,800 It is important because front-end validation alone 84 00:03:19,800 --> 00:03:21,540 can be bypassed by an attacker, 85 00:03:21,540 --> 00:03:23,760 but using backend validation by itself 86 00:03:23,760 --> 00:03:26,070 could become more expensive or time consuming, 87 00:03:26,070 --> 00:03:28,983 since it relies on your own service to do the validation. 88 00:03:29,820 --> 00:03:33,060 Now, while input validation is critical to perform, 89 00:03:33,060 --> 00:03:34,110 it is important to remember 90 00:03:34,110 --> 00:03:35,760 that it's not a cure-all solution, 91 00:03:35,760 --> 00:03:38,250 and you still need to have a multi-layered approach 92 00:03:38,250 --> 00:03:40,650 to security, known as "defense in depth", 93 00:03:40,650 --> 00:03:43,200 to achieve high levels of security. 94 00:03:43,200 --> 00:03:46,410 This might include using secure communication protocols, 95 00:03:46,410 --> 00:03:47,730 regular security auditing, 96 00:03:47,730 --> 00:03:49,680 and implementing proper error handling 97 00:03:49,680 --> 00:03:52,980 to implement your own defense in depth strategy. 98 00:03:52,980 --> 00:03:56,100 Next, let's discuss the use of secure cookies. 99 00:03:56,100 --> 00:03:59,520 Cookies are small pieces of data stored on a user's computer 100 00:03:59,520 --> 00:04:02,310 by the web browser while browsing a website. 101 00:04:02,310 --> 00:04:03,969 They are used to maintain staple information 102 00:04:03,969 --> 00:04:06,420 between the web server and the client. 103 00:04:06,420 --> 00:04:09,750 However, if not properly secured, cookies can be exploited 104 00:04:09,750 --> 00:04:13,320 to hijack user sessions or steal sensitive data. 105 00:04:13,320 --> 00:04:15,780 Secure cookies are a solution to this problem. 106 00:04:15,780 --> 00:04:19,019 They are transmitted over a secure HTTPS connection 107 00:04:19,019 --> 00:04:20,820 to prevent potential eavesdroppers 108 00:04:20,820 --> 00:04:22,560 from intercepting the cookie data. 109 00:04:22,560 --> 00:04:25,620 For example, a baking website would use secure cookies 110 00:04:25,620 --> 00:04:27,870 to store session information to ensure that, 111 00:04:27,870 --> 00:04:30,180 even if an attacker can intercept network traffic, 112 00:04:30,180 --> 00:04:33,240 they cannot read or modify the cookie data. 113 00:04:33,240 --> 00:04:35,460 There are some practices that you should be aware of 114 00:04:35,460 --> 00:04:36,840 when utilizing cookies. 115 00:04:36,840 --> 00:04:39,900 You should always refrain from utilizing persistent cookies 116 00:04:39,900 --> 00:04:41,490 for session verification. 117 00:04:41,490 --> 00:04:44,010 Instead, you should always generate a fresh cookie 118 00:04:44,010 --> 00:04:45,840 each time the user authenticates again 119 00:04:45,840 --> 00:04:48,630 to prevent session hijacking from occurring. 120 00:04:48,630 --> 00:04:52,020 Also, you should enable the secure attribute on the cookie 121 00:04:52,020 --> 00:04:53,820 to ensure that a cookie is not transmitted 122 00:04:53,820 --> 00:04:57,480 over an insecure HTTP connection accidentally. 123 00:04:57,480 --> 00:04:59,280 To protect your cookies from being reachable 124 00:04:59,280 --> 00:05:03,000 within a document object model or by a client-side script, 125 00:05:03,000 --> 00:05:05,261 you should enable the HttpOnly attribute 126 00:05:05,261 --> 00:05:06,990 in the cookie itself. 127 00:05:06,990 --> 00:05:08,820 If you need to control which origin 128 00:05:08,820 --> 00:05:10,380 can access a given cookie, 129 00:05:10,380 --> 00:05:13,380 you can configure the SameSite attribute on the cookie 130 00:05:13,380 --> 00:05:14,790 so that it reduces the risk 131 00:05:14,790 --> 00:05:17,040 of a cross-site request forgery attack 132 00:05:17,040 --> 00:05:19,020 from being successful. 133 00:05:19,020 --> 00:05:22,020 Next on our list is static code analysis. 134 00:05:22,020 --> 00:05:23,220 Static code analysis, 135 00:05:23,220 --> 00:05:27,270 also known as static application security testing, or SAST, 136 00:05:27,270 --> 00:05:29,610 is a method of debugging and application 137 00:05:29,610 --> 00:05:31,950 by reviewing and examining its source code 138 00:05:31,950 --> 00:05:34,290 before the program is ever run. 139 00:05:34,290 --> 00:05:37,440 Static code analysis is designed to analyze source code 140 00:05:37,440 --> 00:05:40,500 for potential vulnerabilities, such as buffer overflows, 141 00:05:40,500 --> 00:05:43,380 SQL injection, and cross-site scripting attacks, 142 00:05:43,380 --> 00:05:45,090 as well as ensure that the programmers 143 00:05:45,090 --> 00:05:47,430 have implemented proper input validation 144 00:05:47,430 --> 00:05:50,610 into the front-end and back-end of the code. 145 00:05:50,610 --> 00:05:53,100 For example, a static code analysis tool 146 00:05:53,100 --> 00:05:54,660 might flag a piece of code 147 00:05:54,660 --> 00:05:58,980 that concatenates a user provided string into a SQL query. 148 00:05:58,980 --> 00:06:00,390 This could potentially lead 149 00:06:00,390 --> 00:06:02,700 to an SQL injection vulnerability 150 00:06:02,700 --> 00:06:04,050 if the user-provided string 151 00:06:04,050 --> 00:06:06,450 contains a malicious SQL command. 152 00:06:06,450 --> 00:06:09,330 Instead, the program should perform input validation 153 00:06:09,330 --> 00:06:10,620 on the user-entered string 154 00:06:10,620 --> 00:06:13,380 before passing it to the SQL database server. 155 00:06:13,380 --> 00:06:15,780 Alternatively, you could code the program 156 00:06:15,780 --> 00:06:17,936 so that it only utilizes templated queries 157 00:06:17,936 --> 00:06:21,480 instead of allowing for a direct input of a search term 158 00:06:21,480 --> 00:06:24,120 by the user to prevent security issues. 159 00:06:24,120 --> 00:06:26,250 Static code analysis is usually performed 160 00:06:26,250 --> 00:06:28,020 using software analyzers. 161 00:06:28,020 --> 00:06:30,630 The analysis software must support the programming language 162 00:06:30,630 --> 00:06:32,040 used by the source code. 163 00:06:32,040 --> 00:06:34,830 Now, if you perform this code review using a human 164 00:06:34,830 --> 00:06:37,260 instead of a static software analysis tool, 165 00:06:37,260 --> 00:06:39,750 we refer to this as manual code review. 166 00:06:39,750 --> 00:06:41,760 When conducting manual code reviews, 167 00:06:41,760 --> 00:06:44,700 we usually assign a different programmer to review the code 168 00:06:44,700 --> 00:06:46,680 than the person who initially wrote the code. 169 00:06:46,680 --> 00:06:49,170 Also, it helps us find any mistaken assumptions 170 00:06:49,170 --> 00:06:52,500 or uncover any lack of knowledge or experience 171 00:06:52,500 --> 00:06:55,350 that the initial programmer may have had. 172 00:06:55,350 --> 00:06:58,710 Next, we can also utilize dynamic code analysis 173 00:06:58,710 --> 00:07:01,920 to find additional vulnerabilities in our applications. 174 00:07:01,920 --> 00:07:03,270 A dynamic code analysis, 175 00:07:03,270 --> 00:07:05,910 also known as a dynamic application security testing, 176 00:07:05,910 --> 00:07:08,670 or DAST, is a testing method 177 00:07:08,670 --> 00:07:11,670 that analyzes an application while it's running. 178 00:07:11,670 --> 00:07:14,670 Dynamic code analysis is designed to find vulnerabilities 179 00:07:14,670 --> 00:07:16,890 that a static code analysis might miss, 180 00:07:16,890 --> 00:07:20,070 such as runtime errors and memory leaks. 181 00:07:20,070 --> 00:07:21,750 A dynamic code analysis tool 182 00:07:21,750 --> 00:07:23,460 might interact with a web application, 183 00:07:23,460 --> 00:07:26,460 provide various inputs, and observe the related outputs 184 00:07:26,460 --> 00:07:28,680 to identify any potential vulnerabilities. 185 00:07:28,680 --> 00:07:32,160 For example, if the tool inputs a script into a form field 186 00:07:32,160 --> 00:07:34,740 and the application returns the script in its response 187 00:07:34,740 --> 00:07:37,080 without proper encoding, this could indicate 188 00:07:37,080 --> 00:07:40,080 a potential cross-site scripting vulnerability. 189 00:07:40,080 --> 00:07:42,000 When it comes to dynamic code analysis, 190 00:07:42,000 --> 00:07:43,320 the two most common methods 191 00:07:43,320 --> 00:07:44,940 of conducting dynamic code analysis 192 00:07:44,940 --> 00:07:46,833 is fuzzing and stress testing. 193 00:07:47,670 --> 00:07:49,830 Fuzzing, also known as fuzz testing, 194 00:07:49,830 --> 00:07:51,450 is a software testing technique 195 00:07:51,450 --> 00:07:54,360 used to discover coding errors and security loopholes 196 00:07:54,360 --> 00:07:57,030 in software, operating systems, or networks 197 00:07:57,030 --> 00:08:00,300 by inputting massive amounts of random data called fuzz 198 00:08:00,300 --> 00:08:02,670 to the system in an attempt to make it crash. 199 00:08:02,670 --> 00:08:05,430 The process of fuzzing involves the automated injection 200 00:08:05,430 --> 00:08:08,700 of malformed or unexpected data into the system, 201 00:08:08,700 --> 00:08:11,190 and then monitoring for exceptions, such as crashes, 202 00:08:11,190 --> 00:08:15,270 failing built-in code assertions, or potential memory leaks. 203 00:08:15,270 --> 00:08:17,490 Stress testing is a type of software testing 204 00:08:17,490 --> 00:08:19,740 that evaluates the stability and reliability 205 00:08:19,740 --> 00:08:21,750 of a system under extreme conditions. 206 00:08:21,750 --> 00:08:22,920 The goal of stress testing 207 00:08:22,920 --> 00:08:24,900 is to identify the system's weak points 208 00:08:24,900 --> 00:08:27,360 and determine how it behaves under intense loads 209 00:08:27,360 --> 00:08:29,400 and how it recovers from failure. 210 00:08:29,400 --> 00:08:31,890 For example, a website might be stress tested 211 00:08:31,890 --> 00:08:34,590 by simulating thousands or millions of users 212 00:08:34,590 --> 00:08:36,659 accessing the site simultaneously. 213 00:08:36,659 --> 00:08:39,240 This can help identify bottlenecks in the system, 214 00:08:39,240 --> 00:08:41,280 test the effectiveness of load balancing, 215 00:08:41,280 --> 00:08:44,553 and ensure that the system can handle high traffic volumes. 216 00:08:45,390 --> 00:08:47,070 All right, now that we have discussed 217 00:08:47,070 --> 00:08:48,870 some different code analysis techniques, 218 00:08:48,870 --> 00:08:51,600 let's discuss a way that a programmer can attest 219 00:08:51,600 --> 00:08:54,600 to the fact that they wrote a specific application. 220 00:08:54,600 --> 00:08:56,897 To do this, we utilize code signing. 221 00:08:56,897 --> 00:08:59,947 Code signing is a technique used to confirm the identity 222 00:08:59,947 --> 00:09:02,100 of the software author and guarantee 223 00:09:02,100 --> 00:09:04,110 that the code has not been altered or corrupted 224 00:09:04,110 --> 00:09:05,640 since it was signed. 225 00:09:05,640 --> 00:09:08,130 Code signing involves using a digital signature 226 00:09:08,130 --> 00:09:10,683 to authenticate the software source and integrity. 227 00:09:11,520 --> 00:09:13,530 Code signing is the main way to confirm 228 00:09:13,530 --> 00:09:16,230 that a piece of code, like a program or script, 229 00:09:16,230 --> 00:09:18,180 is genuine and hasn't been tampered with 230 00:09:18,180 --> 00:09:20,730 since it was distributed by the developers. 231 00:09:20,730 --> 00:09:23,850 The process works by having the developer make a unique code 232 00:09:23,850 --> 00:09:26,730 called a cryptographic hash of the file 233 00:09:26,730 --> 00:09:28,080 and then encrypting that hash 234 00:09:28,080 --> 00:09:30,300 using the developer's own private key 235 00:09:30,300 --> 00:09:34,140 to create a digital signature of the program's file. 236 00:09:34,140 --> 00:09:36,090 Whenever the program is sent out next, 237 00:09:36,090 --> 00:09:37,410 it will come with a copy 238 00:09:37,410 --> 00:09:40,080 of the developer's code signing certificate. 239 00:09:40,080 --> 00:09:42,060 This certificate has a public key 240 00:09:42,060 --> 00:09:44,010 that the receiving computer uses to check 241 00:09:44,010 --> 00:09:46,500 and confirm that the signature is valid. 242 00:09:46,500 --> 00:09:49,050 Then, the operating system ask the user to decide 243 00:09:49,050 --> 00:09:50,370 if they trust the signature 244 00:09:50,370 --> 00:09:53,190 and want to run and install the given program. 245 00:09:53,190 --> 00:09:55,440 For example, when you download an application 246 00:09:55,440 --> 00:09:57,789 from the Apple App Store, you can be confident 247 00:09:57,789 --> 00:09:59,430 that the application is genuine 248 00:09:59,430 --> 00:10:00,570 and hasn't been tampered with 249 00:10:00,570 --> 00:10:03,300 since it was uploaded by the developer. 250 00:10:03,300 --> 00:10:06,330 This is because Apple requires all applications to be signed 251 00:10:06,330 --> 00:10:07,710 with the developer certificate 252 00:10:07,710 --> 00:10:10,290 before they can publish it to the App Store. 253 00:10:10,290 --> 00:10:12,600 It is crucial to understand that the process 254 00:10:12,600 --> 00:10:15,060 of digital signatures on a file or program 255 00:10:15,060 --> 00:10:17,280 does not guarantee its absolute security 256 00:10:17,280 --> 00:10:19,500 or the absence of vulnerabilities. 257 00:10:19,500 --> 00:10:22,560 However, what it does ensure is that the file or program 258 00:10:22,560 --> 00:10:23,610 has not been tampered with 259 00:10:23,610 --> 00:10:26,400 since the developer originally created and signed it. 260 00:10:26,400 --> 00:10:28,313 In other words, the digital signature confirms 261 00:10:28,313 --> 00:10:30,210 that the file is in the same state 262 00:10:30,210 --> 00:10:31,830 that the developer intended it to be 263 00:10:31,830 --> 00:10:33,570 when they distributed it. 264 00:10:33,570 --> 00:10:36,060 Finally, let's talk about sandboxing. 265 00:10:36,060 --> 00:10:38,010 Sandboxing is a security mechanism 266 00:10:38,010 --> 00:10:40,110 that is used to isolate running programs 267 00:10:40,110 --> 00:10:42,133 by limiting the resources that they can access 268 00:10:42,133 --> 00:10:45,420 and the changes that they can make to a system. 269 00:10:45,420 --> 00:10:48,011 Sandboxing is a method of executing untested 270 00:10:48,011 --> 00:10:51,210 or untrusted programs without risking harm 271 00:10:51,210 --> 00:10:53,310 to the host device or network. 272 00:10:53,310 --> 00:10:56,280 For example, when you open a potential harmful website 273 00:10:56,280 --> 00:10:58,547 in your browser, the browser runs the website's code 274 00:10:58,547 --> 00:11:00,030 in the sandbox. 275 00:11:00,030 --> 00:11:02,190 This means that even if the website tries 276 00:11:02,190 --> 00:11:03,810 to execute malicious code, 277 00:11:03,810 --> 00:11:06,210 it won't be able to affect your entire computer 278 00:11:06,210 --> 00:11:08,550 because it's confined to the web browser sandbox 279 00:11:08,550 --> 00:11:10,260 in most cases. 280 00:11:10,260 --> 00:11:13,500 These sandboxes provide a more comprehensive solution 281 00:11:13,500 --> 00:11:15,600 than a typical anti-malware tool would, 282 00:11:15,600 --> 00:11:18,420 since they allow for testing code under various environments 283 00:11:18,420 --> 00:11:20,610 and not just the current system configuration, 284 00:11:20,610 --> 00:11:23,670 since you can run numerous sandboxes on one system 285 00:11:23,670 --> 00:11:25,950 using different operating systems. 286 00:11:25,950 --> 00:11:29,880 For example, I am running a Mac OS on my MacBook Pro. 287 00:11:29,880 --> 00:11:32,640 I can also run a sandbox that contains Mac OS 288 00:11:32,640 --> 00:11:34,290 as its operating system, as well as sandboxes 289 00:11:34,290 --> 00:11:36,330 with a Linux operating system 290 00:11:36,330 --> 00:11:39,030 or a Windows operating system as well. 291 00:11:39,030 --> 00:11:42,570 So remember, in the world of application security, 292 00:11:42,570 --> 00:11:46,140 we need to consider six key areas, input validation, 293 00:11:46,140 --> 00:11:49,980 secure cookies, static code analysis, dynamic code analysis, 294 00:11:49,980 --> 00:11:52,500 code signing, and sandboxing. 295 00:11:52,500 --> 00:11:55,920 Input validation is designed to act as a vigilant gatekeeper 296 00:11:55,920 --> 00:11:58,950 that ensures that our applications only process well-defined 297 00:11:58,950 --> 00:12:02,700 and untainted data to counteract various forms of attacks. 298 00:12:02,700 --> 00:12:04,920 Secure cookies help to prevent vulnerabilities 299 00:12:04,920 --> 00:12:07,860 like session hijacking through the secure transmission 300 00:12:07,860 --> 00:12:11,250 and using the proper attribute settings on the cookies. 301 00:12:11,250 --> 00:12:12,300 Static code analysis 302 00:12:12,300 --> 00:12:14,520 involves proactive vulnerability detection 303 00:12:14,520 --> 00:12:16,080 through source code review. 304 00:12:16,080 --> 00:12:20,280 Dynamic code analysis is used to uncover any runtime issues. 305 00:12:20,280 --> 00:12:21,900 Code signing provides a means 306 00:12:21,900 --> 00:12:24,240 to verify the software authenticity, 307 00:12:24,240 --> 00:12:27,510 and sandboxing is used to isolate any untrusted code 308 00:12:27,510 --> 00:12:30,630 to mitigate its ability to potentially cause harm. 309 00:12:30,630 --> 00:12:32,310 These multifaceted security measures, 310 00:12:32,310 --> 00:12:34,770 when integrated into software development practices, 311 00:12:34,770 --> 00:12:37,230 help to create a robust defense strategy 312 00:12:37,230 --> 00:12:40,080 against the ever-evolving world of cybersecurity threats.