Paroksh Sharma is a Director at NetSPI. He graduated with a Master’s Degree in Computer Science from the University of Texas at Dallas with specialization in Information Security. He has over 8 years of experience in identifying and remediating software security vulnerabilities for a variety of organizations including financial and technology companies. Paroksh has assisted clients in maturing secure software development life cycle, integrating secure code review in DevOps workflow, and cloud security configuration reviews. He also has development background in Java. In his role at NetSPI, Paroksh is responsible for leading secure code review practice.
We’ve made it to the two-year anniversary of the SolarWinds cybersecurity breach. Not the anniversary of its public disclosure, but during Fall 2019 attackers first gained access to the SolarWinds systems. There’s a lot to learn from the breach. The biggest takeaway? Supply chain vulnerabilities are not to be taken lightly.
The breach highlights the significance of a thorough and robust review of security vulnerabilities in the source code of software products – namely hidden backdoors. Analyzing the attack, the threat actors were able to inject malicious code and successfully masquerade the payload, which should have been detected during a secure code review or audit activity focused on finding anomalies or a malicious piece of code.
While many software suppliers today do some form of secure code review activity on their software, there are major variations in the depth and breadth of reviews performed across companies that can drastically impact results. In this blog, I’ll dive into the secure code review process and explain the necessary components needed to identify the risk your source code may pose to your organization if it is not reviewed thoroughly.
What is a Secure Code Review?
For a detailed and digestible breakdown of secure code review, read OWASP’s Code Review Guide. The authors reiterate that “secure code review is the single-most effective technique for identifying security bugs early in the system development lifecycle.” Let’s start with the basics:
As I define it, secure code review is a process used to verify if the source code being developed contains security flaws and that it has the necessary security controls to prevent an adversary – external or internal – from exploiting vulnerabilities in software.
In other words, the purpose of a secure code review is not only to find security vulnerabilities but also to evaluate if the source code is robust enough to evade security attacks. In addition, it can also verify that developers are following your secure development policies and procedures.
While penetration testing can help you look at your application security holistically, supplementing your testing strategy with a secure code review allows for more comprehensive coverage. According to the OWASP Code Review Guide, “a general rule of thumb is that a penetration test should not discover any additional application vulnerabilities relating to the developed code after the application has undergone a proper security code review.”
When Should I Implement Secure Code Review or Static Analysis?
Depending on the criticality of the application and AppSec program maturity, security teams may implement secure code review at various touchpoints in the SDLC or bake it into an Agile development process.
Just as penetration testing adds more value to your security program when it is implemented continuously, secure code review – when done incrementally and across the SDLC – can dramatically improve your secure software development lifecycle. Below, I outline five key timeframes where secure code review or static application security testing (SAST) should be implemented:
During development: Integrating security scanning directly into the developer’s integrated development environment (IDE) is a great way to avoid introducing security vulnerabilities in your code as the software is being written. It provides real-time feedback on secure coding guidelines and is also a great tool to help your teams get in the habit of secure development. Finding and fixing vulnerabilities during development ensures they do not get propagated further down the road. According to National Institute of Standards and Technologies (NIST), the cost of fixing a security defect once it's made it to production can be up to 60 times more expensive than during the development cycle.
Pre-commit checks (pull/merge requests): When merging code from multiple developers into a single branch, it is highly likely that security vulnerabilities will be introduced. While peer code reviews on pull requests generally focus on functional bugs, it is recommended to also do a quick check on security issues. This will help eliminate critical and high severity issues early in the chain. Today, all popular code repositories with code collaboration features provide integration with SAST tools. However, automated tools tend to be too noisy and should be carefully configured with limited rulesets at this stage to not significantly impact developer workflow.
Post-commit (during build/testing phase): As source code gets ready to be part of final release of a product, a thorough secure code review is critical to ensure the product is free of security bugs. SAST tools with a broader ruleset can be integrated into continuous integration pipelines to report on existing security vulnerabilities, which can be reported into bug trackers or team backlogs.
However, breaking the build every time a security bug is reported may not be viable, since tools are prone to false positives. One can improve static analyzers by refining rulesets using regular feedback from reported issues.
Post deployment: While integrating static analysis tools in the DevSecOps pipeline may seem straight forward, the speed at which new code is expected to release makes it harder to find and fix all security bugs in every sprint or release.
Running a SAST scan periodically from production code repositories and having scheduled secure code reviews implemented into your annual calendar will help give your security posture a boost. Also, these help meet the requirements of governing bodies and regulations such as PCI DSS and HIPAA.
To eliminate noise and reduce the workload on developers, these scans should be triaged by your product security experts, or “champions,” who can closely work with the developers to resolve vulnerabilities. However, not all organizations are adequately staffed with security analysts that have secure code review skills making partnering with a secure code review vendor a viable option.
Suspicion of malicious intent: This is a more reactive strategy for secure code review. When you’re suspicious of malicious activity in your organization, or have detected a potential breach, do an on-demand code review scan to validate your suspicions and identify the breach at its core.
Remember that code review activities should be aligned with your organizations goals and provide value. For example, in case of malicious threat vectors, review should be focused on identifying points of interest (POI) in code that can combine to produce malicious constructs. Analyze the interaction between various POIs, looking for mutation, obfuscation, and inversion of control used to conceal malicious activity.
The Secure Code Review Process
There are many variables that can impact the secure code review process. As mentioned at the beginning of this article, the depth and breadth of a secure code review can vary greatly. To get the most out of your testing, here are four areas that can make the biggest difference:
Define the Scope The scope of each secure code review will vary based upon a multitude of factors, including the threat factors involved, the coding languages, number of lines of code, and the criticality of the application. Is it a “crown jewel” application? If so, it will be important to increase the frequency of your code review cycles and put emphasis on the remediation of vulnerabilities.
Custom Checklists Predefined, custom checklists based on the threat model of your product are essential for secure code review success. Generic checklists aren’t very helpful, considering application security is not one-size-fits-all. Custom checklists for each software application can be extremely time-consuming. To help, use frameworks such as the OWASP Application Security Verification Standard as a starting point. Lastly, and perhaps most importantly, ensure your checklists are consistently maintained and updated.
Automated Scanning Automated vulnerability scanning enables manual testers to spend more time finding business-critical vulnerabilities in the code. All automated scanning tools are not created equally – some are better than others and some meet unique needs. Are your tools meeting your requirements? Are you being strategic with your automated scanning? Audit and recognize whether there are existing gaps in your tooling and have a plan to evolve and enhance your technologies. Look for these three qualities in your automated scanning tools: the ability to be customized, integrate into the CI/CD pipeline, and reduce noise/false positives.
Manual Testing To find vulnerabilities that tools miss, human context is necessary. Manual secure code review is especially important for high-risk, sensitive applications – the one with greater business risk. Humans can apply the needed business logic to write custom scripts and approach a secure code review from the perspective of a real adversary. Additionally, with automation, comes false positives. Having a human triage, the vulnerabilities found in your code is a huge benefit – consuming a raw, data-heavy report is not enough.
How to Choose Your Secure Code Review Team
To outsource or not to outsource. There are benefits to building a secure code review team within your organization, but it does require a lot of investment and time to evolve your tools and train new resources. Do you have the capacity to maintain the automated scanners, increase the frequency of your secure code review, and update your checklists? If not, here are four reasons to consider working with a secure code review provider:
Better coverage (more vulnerability findings) because they are focused on one activity vs. internal teams who are typically pulled into many different security activities.
Work with your vendor to find the best balance between automated scanning and manual testing.
Contextual remediation recommendations. Plus, the development of code libraries that can be leveraged for remediation.
As discussed above, to prevent your organization from falling victim to next major supply chain attack implementing regular secure code reviews is an essential touchpoint. While continuous static analysis checks provide valuable integration in development environment, adoption should be incremental as per your program goals – and without significantly impacting developer workflow. Collecting feedback from SAST tools, customizing rulesets, and adopting manual code review and verification process are all useful contributors to enhance your application security posture.
[post_title] => The Importance of Reviewing Source Code for Security Vulnerabilities: Two Years After the SolarWinds Breach
[post_excerpt] => Dive into the secure code review process and learn about the necessary components needed to identify the risk your source code may pose to your organization.
[post_status] => publish
[comment_status] => closed
[ping_status] => closed
[post_password] =>
[post_name] => importance-of-reviewing-source-code-for-security-vulnerabilities
[to_ping] =>
[pinged] =>
[post_modified] => 2022-12-16 10:51:49
[post_modified_gmt] => 2022-12-16 16:51:49
[post_content_filtered] =>
[post_parent] => 0
[guid] => https://www.netspi.com/?p=26507
[menu_order] => 360
[post_type] => post
[post_mime_type] =>
[comment_count] => 0
[filter] => raw
)
[1] => WP_Post Object
(
[ID] => 20336
[post_author] => 70
[post_date] => 2020-11-10 07:00:21
[post_date_gmt] => 2020-11-10 07:00:21
[post_content] =>
Today, nearly every company is a software company, resulting in an unbelievable amount of code that’s subject to security issues. What’s more, a myriad of methods for identifying vulnerabilities focus heavily on a post-deployment approach, leaving security gaps between development and testing.
It’s time to shift left.
By shifting left and introducing secure code review (SCR) the moment the first line of code is written (or as soon in the software development lifecycle as possible), any organization creating applications can identify real vulnerabilities well in advance of deployment, thereby increasing team productivity and thwarting future outside attacks, all while decreasing costs of testing for vulnerabilities too late in the software development life cycle (SDLC). SCR coupled with pentest and threat modelling engagements provides the most in-depth application security testing coverage. It is an essential strategy to any application security strategy. To learn more, read 3 Steps to Reimagine Your AppSec Program in Cyber Defense Magazine.
If not done right, failed SCR programs can cause organizations to lose valuable time, money, and effort. It’s important to develop a SCR program that offers risk context, uses the right tools, has set processes and standards, and doesn’t overwhelm application teams with false positives. Ultimately, the challenge lies in the fact that creating and running a SCR program is not straight forward and one strategy may not fit all organizations. It requires ongoing planning, discussion and possibly, organizational changes. To help, we’ve compiled five steps to get you started on the right path.
Step 1: Develop a Security Culture and Listen to Your Developers
SCR program planning should not be done by security people alone – be sure to include your experienced developers and application teams when discussing strategies for selecting the right platform, integrating tools in the development ecosystem, and assessing and improving the process.
A solid security culture also aligns code review activity toward assisting developers in writing secure code rather than appearing as an additional burden that delays the release within an already restricted timeline. In other words, look at secure code review as a way to empower developers to write secure code from the start.
Another important element to developing a strong security culture is to rotate code reviewers. This ensure that your source code is regularly reviewed with a fresh pair of eyes and secure code reviewers get exposure to different development environments.
For enterprise organizations, hold awareness sessions during which various teams share common mistakes or top findings – without calling out the developers. And, when developers do write highly secure code, encourage them to continue to do so with rewards that they find meaningful.
Step 2: Create Simple and Effective Methodology and Processes
Lack of transparency and simplicity in a SCR program can lead to loss of time and frustration, which is why streamlined, clearly documented processes, policies, and guidelines are critical for success. Information that should be made available to all teams include items such as defining expectations, scan frequencies, and how to approach remediation (see below). Above all, keep it simple.
One key to keeping it simple is automation, which should be leveraged to run scans and to track issues and remediation progress. However, customizing off-the-shelf tools is equally as important. But don’t rely on tools solely – while automated tools are useful in finding vulnerabilities in less time, there will always be a certain category of issues that they won’t identify Make an effort to contextualize your code review process by understanding the application’s use case and underlying framework issues. Conducting manual secure code reviews is essential to finding those hidden culprits, particularly in critical applications.
Step 3: Plan Application Onboarding and Scan Frequency
When you’re implementing a SCR program, you need to consider multiple factors. Whether you have a large or small inventory of applications, a risk-based approach to scope and static analysis is essential. In other words, prioritize your “crown jewels,” business critical applications or those with sensitive data. Scan them more closely and frequently than internal applications that do not contain critical data.
In terms of scan frequency, many organizations adhere to “once-a-year minimum” compliance guidelines to scan all applications or at few major releases. This approach does not work for all applications within a portfolio, however. Instead, leverage static analysis automation tools as frequently as possible in the CI/CD pipeline.
If your organization is moving to an agile environment, where you do development work in sprints, another approach to application onboarding is to implement a separate code review sprint. We all know how much pressure sprints can place on teams to create new code within a constrained timeframe. By dedicating a security sprint that’s separate from the development sprint, you can achieve secure code without delay and within specified deadlines. If you decide to take this approach, we recommend implementing a lightweight secure code review during pre-commit, when new code is reviewed before it is introduced into the code base, to eliminate the introduction of security issues early in the cycle.
Step 4: Understand That Remediation Matters Most
Code reviews are great, but don’t stop there. Once you have your list of vulnerabilities, make sure you also have a plan to remediate them, and enable your developers to do so properly with remediation libraries and guidelines at their fingertips. Include:
Tools that identify security issues and give feedback as developers are coding
Readouts after every assessment, thereby giving developers time to examine identified issues and raise questions
Clear deadlines for fixing problems
Training to enable developers write secure code
Step 5: Measure and Improve
What you don’t measure, you can’t improve. If you want your secure code reviews to improve over time, then measure and track your progress (or lack thereof). Determine what your key metrics are and find opportunities to gather the appropriate data. Ask yourself questions like:
What is your remediation rate?
How much time is remediation taking? Is it increasing or decreasing?
Are you discovering the same type of security issues and what action should be taken to avoid that ?
Are developers learning anything from your vulnerability reports? That is, are they writing better code or are they reintroducing the same issues over and over?
Examine your organization’s performance against your key metrics on a regular basis – quarterly or yearly. Additionally, look beyond code review activity within your own organization to what others are doing. Where do you stand amongst your peers? What are they doing differently?
The ultimate goal of any SCR program is to reduce the time, cost, and effort spent on identifying and fixing security issues that are captured later in the SDLC. The more effective your SCR program is, the less time and money will be spent on analyzing and remediating issues after an application has been deployed.
[post_title] => Shifting Left to Move Forward: Five Steps for Building an Effective Secure Code Review Program
[post_excerpt] => Today, nearly every company is a software company, resulting in an unbelievable amount of code that’s subject to security issues.
[post_status] => publish
[comment_status] => closed
[ping_status] => closed
[post_password] =>
[post_name] => shifting-left-to-move-forward-five-steps-for-building-an-effective-secure-code-review-program
[to_ping] =>
[pinged] =>
[post_modified] => 2021-04-14 06:39:45
[post_modified_gmt] => 2021-04-14 06:39:45
[post_content_filtered] =>
[post_parent] => 0
[guid] => https://www.netspi.com/?p=20336
[menu_order] => 456
[post_type] => post
[post_mime_type] =>
[comment_count] => 0
[filter] => raw
)
)
[post_count] => 2
[current_post] => -1
[before_loop] => 1
[in_the_loop] =>
[post] => WP_Post Object
(
[ID] => 26507
[post_author] => 70
[post_date] => 2021-10-05 07:00:00
[post_date_gmt] => 2021-10-05 12:00:00
[post_content] =>
We’ve made it to the two-year anniversary of the SolarWinds cybersecurity breach. Not the anniversary of its public disclosure, but during Fall 2019 attackers first gained access to the SolarWinds systems. There’s a lot to learn from the breach. The biggest takeaway? Supply chain vulnerabilities are not to be taken lightly.
The breach highlights the significance of a thorough and robust review of security vulnerabilities in the source code of software products – namely hidden backdoors. Analyzing the attack, the threat actors were able to inject malicious code and successfully masquerade the payload, which should have been detected during a secure code review or audit activity focused on finding anomalies or a malicious piece of code.
While many software suppliers today do some form of secure code review activity on their software, there are major variations in the depth and breadth of reviews performed across companies that can drastically impact results. In this blog, I’ll dive into the secure code review process and explain the necessary components needed to identify the risk your source code may pose to your organization if it is not reviewed thoroughly.
What is a Secure Code Review?
For a detailed and digestible breakdown of secure code review, read OWASP’s Code Review Guide. The authors reiterate that “secure code review is the single-most effective technique for identifying security bugs early in the system development lifecycle.” Let’s start with the basics:
As I define it, secure code review is a process used to verify if the source code being developed contains security flaws and that it has the necessary security controls to prevent an adversary – external or internal – from exploiting vulnerabilities in software.
In other words, the purpose of a secure code review is not only to find security vulnerabilities but also to evaluate if the source code is robust enough to evade security attacks. In addition, it can also verify that developers are following your secure development policies and procedures.
While penetration testing can help you look at your application security holistically, supplementing your testing strategy with a secure code review allows for more comprehensive coverage. According to the OWASP Code Review Guide, “a general rule of thumb is that a penetration test should not discover any additional application vulnerabilities relating to the developed code after the application has undergone a proper security code review.”
When Should I Implement Secure Code Review or Static Analysis?
Depending on the criticality of the application and AppSec program maturity, security teams may implement secure code review at various touchpoints in the SDLC or bake it into an Agile development process.
Just as penetration testing adds more value to your security program when it is implemented continuously, secure code review – when done incrementally and across the SDLC – can dramatically improve your secure software development lifecycle. Below, I outline five key timeframes where secure code review or static application security testing (SAST) should be implemented:
During development: Integrating security scanning directly into the developer’s integrated development environment (IDE) is a great way to avoid introducing security vulnerabilities in your code as the software is being written. It provides real-time feedback on secure coding guidelines and is also a great tool to help your teams get in the habit of secure development. Finding and fixing vulnerabilities during development ensures they do not get propagated further down the road. According to National Institute of Standards and Technologies (NIST), the cost of fixing a security defect once it's made it to production can be up to 60 times more expensive than during the development cycle.
Pre-commit checks (pull/merge requests): When merging code from multiple developers into a single branch, it is highly likely that security vulnerabilities will be introduced. While peer code reviews on pull requests generally focus on functional bugs, it is recommended to also do a quick check on security issues. This will help eliminate critical and high severity issues early in the chain. Today, all popular code repositories with code collaboration features provide integration with SAST tools. However, automated tools tend to be too noisy and should be carefully configured with limited rulesets at this stage to not significantly impact developer workflow.
Post-commit (during build/testing phase): As source code gets ready to be part of final release of a product, a thorough secure code review is critical to ensure the product is free of security bugs. SAST tools with a broader ruleset can be integrated into continuous integration pipelines to report on existing security vulnerabilities, which can be reported into bug trackers or team backlogs.
However, breaking the build every time a security bug is reported may not be viable, since tools are prone to false positives. One can improve static analyzers by refining rulesets using regular feedback from reported issues.
Post deployment: While integrating static analysis tools in the DevSecOps pipeline may seem straight forward, the speed at which new code is expected to release makes it harder to find and fix all security bugs in every sprint or release.
Running a SAST scan periodically from production code repositories and having scheduled secure code reviews implemented into your annual calendar will help give your security posture a boost. Also, these help meet the requirements of governing bodies and regulations such as PCI DSS and HIPAA.
To eliminate noise and reduce the workload on developers, these scans should be triaged by your product security experts, or “champions,” who can closely work with the developers to resolve vulnerabilities. However, not all organizations are adequately staffed with security analysts that have secure code review skills making partnering with a secure code review vendor a viable option.
Suspicion of malicious intent: This is a more reactive strategy for secure code review. When you’re suspicious of malicious activity in your organization, or have detected a potential breach, do an on-demand code review scan to validate your suspicions and identify the breach at its core.
Remember that code review activities should be aligned with your organizations goals and provide value. For example, in case of malicious threat vectors, review should be focused on identifying points of interest (POI) in code that can combine to produce malicious constructs. Analyze the interaction between various POIs, looking for mutation, obfuscation, and inversion of control used to conceal malicious activity.
The Secure Code Review Process
There are many variables that can impact the secure code review process. As mentioned at the beginning of this article, the depth and breadth of a secure code review can vary greatly. To get the most out of your testing, here are four areas that can make the biggest difference:
Define the Scope The scope of each secure code review will vary based upon a multitude of factors, including the threat factors involved, the coding languages, number of lines of code, and the criticality of the application. Is it a “crown jewel” application? If so, it will be important to increase the frequency of your code review cycles and put emphasis on the remediation of vulnerabilities.
Custom Checklists Predefined, custom checklists based on the threat model of your product are essential for secure code review success. Generic checklists aren’t very helpful, considering application security is not one-size-fits-all. Custom checklists for each software application can be extremely time-consuming. To help, use frameworks such as the OWASP Application Security Verification Standard as a starting point. Lastly, and perhaps most importantly, ensure your checklists are consistently maintained and updated.
Automated Scanning Automated vulnerability scanning enables manual testers to spend more time finding business-critical vulnerabilities in the code. All automated scanning tools are not created equally – some are better than others and some meet unique needs. Are your tools meeting your requirements? Are you being strategic with your automated scanning? Audit and recognize whether there are existing gaps in your tooling and have a plan to evolve and enhance your technologies. Look for these three qualities in your automated scanning tools: the ability to be customized, integrate into the CI/CD pipeline, and reduce noise/false positives.
Manual Testing To find vulnerabilities that tools miss, human context is necessary. Manual secure code review is especially important for high-risk, sensitive applications – the one with greater business risk. Humans can apply the needed business logic to write custom scripts and approach a secure code review from the perspective of a real adversary. Additionally, with automation, comes false positives. Having a human triage, the vulnerabilities found in your code is a huge benefit – consuming a raw, data-heavy report is not enough.
How to Choose Your Secure Code Review Team
To outsource or not to outsource. There are benefits to building a secure code review team within your organization, but it does require a lot of investment and time to evolve your tools and train new resources. Do you have the capacity to maintain the automated scanners, increase the frequency of your secure code review, and update your checklists? If not, here are four reasons to consider working with a secure code review provider:
Better coverage (more vulnerability findings) because they are focused on one activity vs. internal teams who are typically pulled into many different security activities.
Work with your vendor to find the best balance between automated scanning and manual testing.
Contextual remediation recommendations. Plus, the development of code libraries that can be leveraged for remediation.
As discussed above, to prevent your organization from falling victim to next major supply chain attack implementing regular secure code reviews is an essential touchpoint. While continuous static analysis checks provide valuable integration in development environment, adoption should be incremental as per your program goals – and without significantly impacting developer workflow. Collecting feedback from SAST tools, customizing rulesets, and adopting manual code review and verification process are all useful contributors to enhance your application security posture.
[post_title] => The Importance of Reviewing Source Code for Security Vulnerabilities: Two Years After the SolarWinds Breach
[post_excerpt] => Dive into the secure code review process and learn about the necessary components needed to identify the risk your source code may pose to your organization.
[post_status] => publish
[comment_status] => closed
[ping_status] => closed
[post_password] =>
[post_name] => importance-of-reviewing-source-code-for-security-vulnerabilities
[to_ping] =>
[pinged] =>
[post_modified] => 2022-12-16 10:51:49
[post_modified_gmt] => 2022-12-16 16:51:49
[post_content_filtered] =>
[post_parent] => 0
[guid] => https://www.netspi.com/?p=26507
[menu_order] => 360
[post_type] => post
[post_mime_type] =>
[comment_count] => 0
[filter] => raw
)
[comment_count] => 0
[current_comment] => -1
[found_posts] => 2
[max_num_pages] => 0
[max_num_comment_pages] => 0
[is_single] =>
[is_preview] =>
[is_page] =>
[is_archive] =>
[is_date] =>
[is_year] =>
[is_month] =>
[is_day] =>
[is_time] =>
[is_author] =>
[is_category] =>
[is_tag] =>
[is_tax] =>
[is_search] =>
[is_feed] =>
[is_comment_feed] =>
[is_trackback] =>
[is_home] => 1
[is_privacy_policy] =>
[is_404] =>
[is_embed] =>
[is_paged] =>
[is_admin] =>
[is_attachment] =>
[is_singular] =>
[is_robots] =>
[is_favicon] =>
[is_posts_page] =>
[is_post_type_archive] =>
[query_vars_hash:WP_Query:private] => eea60b3ad772528e89c590fbedbbb73b
[query_vars_changed:WP_Query:private] =>
[thumbnails_cached] =>
[allow_query_attachment_by_filename:protected] =>
[stopwords:WP_Query:private] =>
[compat_fields:WP_Query:private] => Array
(
[0] => query_vars_hash
[1] => query_vars_changed
)
[compat_methods:WP_Query:private] => Array
(
[0] => init_query_flags
[1] => parse_tax_query
)
)
Necessary cookies help make a website usable by enabling basic functions like page navigation and access to secure areas of the website. The website cannot function properly without these cookies.
Name
Domain
Purpose
Expiry
Type
YSC
youtube.com
YouTube session cookie.
52 years
HTTP
Marketing cookies are used to track visitors across websites. The intention is to display ads that are relevant and engaging for the individual user and thereby more valuable for publishers and third party advertisers.
Name
Domain
Purpose
Expiry
Type
VISITOR_INFO1_LIVE
youtube.com
YouTube cookie.
6 months
HTTP
Test
test.com
Testing
7 days
HTTP
Analytics cookies help website owners to understand how visitors interact with websites by collecting and reporting information anonymously.
We do not use cookies of this type.
Preference cookies enable a website to remember information that changes the way the website behaves or looks, like your preferred language or the region that you are in.
We do not use cookies of this type.
Unclassified cookies are cookies that we are in the process of classifying, together with the providers of individual cookies.
We do not use cookies of this type.
Cookies are small text files that can be used by websites to make a user's experience more efficient. The law states that we can store cookies on your device if they are strictly necessary for the operation of this site. For all other types of cookies we need your permission. This site uses different types of cookies. Some cookies are placed by third party services that appear on our pages.
Cookie Settings
Discover how the NetSPI BAS solution helps organizations validate the efficacy of existing security controls and understand their Security Posture and Readiness.
