In today’s fast paced agile world, keeping data safe should be everyone’s job, with collaborative and robust security processes in place. To ensure success, especially with multiple iterations of software being pushed into production daily, we need to have a framework in place that will bring the required people, processes and tools together. One such framework is DevSecOps.

Implementing a DevSecOps framework and culture into your business will reduce the need for large-scale security fixes downstream by enabling your teams to make better decisions at the very beginning of their projects.

We will be building on our in-depth article on DevSecOps to focus on six best practices you should follow to implement a DevSecOps framework in your organization, covering

• 1. Automate
• 2. Check Code dependencies
• 3. One step at a time
• 4. Pick your tools carefully
• 5. Threat modeling
• 6. Secure coding training

Bonus: What makes Bright the perfect tool for DevSecOps

1. Automate

Speed and automation is crucial for DevOps. The time it takes for code to be pushed to production is imperative and security testing must be part of that workflow, without slowing you down. Developers are releasing 100 times more code than 10 years ago and are introducing security vulnerabilities at the same rate too. Manual tests simply can’t keep up with the speed at which organizations release code today and create too many bottlenecks.

Include automated security controls and innovative security scanning (like Bright’s) early and everywhere in the development lifecycle.

2. Check code dependencies

Despite growing concerns, enterprises are using open-source third-party components more than ever before. With the tight schedule and load of tasks, developers often don’t have the time to analyze all the components they use. We need an automated process for managing those components.

For DevSecOps code dependency checks are fundamental, and tools like OWASP Dependency-Check or Snyk can help you make sure you don’t use components with known vulnerabilities in them.

3. One step at a time

When implementing new tools like SAST to a CI/CD chain, security teams often turn on detection of all supported vulnerabilities, causing frustration and possible conflict with developers. The high rate of false positives with these tools can also impact developer adoption.

Start introducing the tool by setting it up so it detects only a few vulnerability categories, such as SQL Injection. This will give your developers time to get familiar with the tool and understand how it helps them detect vulnerabilities while coding. That will increase adoption of the tool, or reduce the likelihood of it being rejected out of hand.

One step at a time – by disrupting things you will just slow down developers and cause possible conflict.

4. Pick your tools carefully

When choosing the right security tools for your organization, you need to consider these main features:

Integration
One of the key aspects you have to consider is the tools ability to seamlessly and easily integrate into the development pipeline, with a direct feedback loop for developers while also providing the security team and management with full visibility.

Developer First Mindset
With DevOps and CI/CD, security tooling needs to be built with developers in mind – for security scanners, developers need to be able to initiate scans quickly, without leaving their existing toolset, controlling scans via code, or to have global configuration files for security governance.

With most legacy tools being built for security professionals, they can be hard to use, configure and understand the output. Ensuring the tooling truly focuses on enabling developers will maximize success, by leveraging your largest team to spearhead your security efforts

Speed and Accuracy
Without automation and speed, your DevOps and CICD pipelines will either grind to a halt or be ineffective. Speed and accuracy of your security tests and findings respectively is paramount to ensure success. The need to run short, fast. incremental scoped defined tests on every build / commit is important, but the accuracy (or inaccuracy in most cases) can really set you back. Manual validation of security finings is a major bottleneck that compounds security and technical debt and makes it impossible to understand your true cyber posture and to prioritize remediation of fixes. 

Ensuring your tool minimizes the number of false positives (or like in Bright’s case, removes them completely), means you can start to trust the output, create tickets and start to remediate issues immediately. 

Learn more in our detailed guide to devsecops tools.

5. Threat modeling

Although at number five on our list, this step should be taken, according to SANS Institute, before shifting to DevSecOps. With threat modeling, your security team will not only get a better understanding of the threats, types and sensitivities of your assets, but also what controls for protecting those assets are already in place and/or lacking. A threat modeling exercise will also help your security team to identify any gaps in your controls that need to be addressed.

Threat modeling can help you identify issues in architecture and design that other approaches might have missed. Unfortunately, threat modeling, unlike almost every other facet of DevSecOps, can’t be automated. For that reason it is often considered as a burden for DevSecOps. Organizations are worried that it could slow down the velocity of a CI/CD environment. But that doesn’t mean you should skip or ignore it.

Threat modeling is crucial for your DevSecOps efforts. It helps your developers change their perspective and look at their software as an attacker would do.

6. Secure coding training 

Although historically a challenge was getting the needed management buy-in, investment and time to train development teams on secure coding practices, this is increasingly becoming more popular and rightly so.  

Developers never intend to create insecure software, but organizations prioritize the speed at which new features are released and that they work properly, over being secure. Providing the right training to developers to prevent them from introducing security bugs into their code is a great way of being secure by design, especially when coupled with a dev-first security scanner.

Learn more in our detailed guide to devsecops vs devops.

What makes Bright Security the perfect tool for DevSecOps

Traditional (legacy) security scanners are built for security professionals, penetration testers and cyber experts, NOT developers. Bright has been built from the ground up to enhance DevSecOps with a developer first approach, enabling you to shift-left:

• Bright integrates early into the SDLC: Unlike traditional DAST tools, Bright integrates early into the SDLC allowing you to detect and remediate vulnerabilities early and often
• Bright tests every aspect of your apps and APIs: Bright is capable of scanning any target, whether web / internal apps, APIs (REST, SOAP, GraphQL, and more) or mobile
• Bright seamlessly integrates with the tools and workflows you already use: Bright works with your existing CI/CD pipelines – it triggers scans on every commit, pull request or build with unit tests
• Developers can spin up, configure and control scans with code: One file. One command. No UI needed
• NO  false-positive: Bright automatically validates every security finding so you don’t have. Start trusting your output

Start automating your security testing in your pipeline – sign up for a free Bright account and try it yourself.  

What Is Penetration Testing?

Penetration testing (pentesting), is a cybersecurity technique used by organizations to identify and remediate security vulnerabilities. Organizations hire ethical hackers to imitate the tactics and behaviors of external attacks. This makes it possible to evaluate their potential to compromise computer systems, networks, or web applications. 

Organizations also use penetration testing to ensure compliance—some compliance standards and regulations require a penetration test to prove that the organization’s systems are secure.

In this article we’ll review the following penetration testing types:

1. Network Penetration Testing
2. Web Application Penetration Testing
3. Wireless Penetration Testing
4. Physical Penetration Testing
5. Social Engineering Penetration Testing
6. Client-Side Penetration Testing
7. IoT Penetration Testing
8. Mobile App Penetration Testing
9. Red Team Penetration Testing

1. Network Penetration Testing

Network penetration testing finds and exploits the most exposed vulnerabilities in network infrastructure such as servers, firewalls, and switches. This type of testing can help protect your business from common network-based attacks, such as:

• Firewall misconfiguration and firewall bypass
• IPS/IDS evasion
• Router attacks
• DNS-level attacks
• Zone transfer attacks
• Switching or routing-based attacks
• SSH attacks
• Proxy server attacks
• Attacks on unnecessary open ports
• Database attacks
• Man-in-the-middle (MitM) attacks
• FTP/SMTP-based attacks

2. Web Application Penetration Testing

Web application penetration testing is used to find vulnerabilities in web-based applications. It uses a three-step process: 

1. Reconnaissance—discovering information about web servers, operating systems, services, resources, and more used by the web application
2. Discovery—finding vulnerabilities in the web applications and planning attack vectors to be used in the penetration test.
3. Attack—exploiting a vulnerability to gain unauthorized access to the application or its data.

Penetration testing of web applications can identify security vulnerabilities in databases, source code, and backend networks of web-based applications. It can not only identify vulnerabilities but also help prioritize them and provide solutions to mitigate them.

Related content: Read our guide to web application penetration testing

3. Wireless Penetration Testing

Wireless communications are services that allow data to move in and out of networks and must be protected from unauthorized access and data exfiltration. Wireless penetration testing is used to identify risks associated with wireless networks and evaluate weaknesses such as: 

• Deauthentication attacks
• Misconfiguration of wireless routers
• Session reuse
• Unauthorized wireless devices

4. Physical Penetration Testing

If a threat actor has physical access to a server room or other sensitive facility, they can potentially compromise the entire network, which can have devastating effects on business, customers, and partnerships. Physical penetration testing can help secure an organization’s physical assets from threats such as social engineering, tailgating, and badge cloning. 

Physical penetration testing finds weaknesses in physical controls such as locks, doors, cameras, or sensors, and allows the organization to quickly remediate defects.

5. Social Engineering Penetration Testing

When it comes to security, users are often considered the weakest link of the security chain, and are a common target for attackers. Social engineering penetration testing focuses people and processes in the organization and the security vulnerabilities associated with them. It is performed by ethical hackers who attempt social engineering attacks which are commonly experienced in the workplace, such as phishing, USB dropping, and spoofing. 

The goal is to identify vulnerable individuals, groups, or processes, and to develop pathways for improving security awareness.

6. Client-Side Penetration Testing

Client-side penetration testing tests can uncover security vulnerabilities in software running on client computers, such as web browsers, media players, and content creation software packages (such as MadCap Flare, Adobe Framemaker, or Adobe RoboHelp). Attackers often compromise client-side software to gain access to company infrastructure.

Perform client-side testing to identify specific network attacks, such as:

• Cross-site scripting attacks (XSS)
• Clickjacking attacks
• Cross-origin resource sharing  (CORS)
• Form hijacking
• HTML injection
• Open redirection
• Malware infection

7. IoT Penetration Testing

IoT penetration testing looks for security vulnerabilities in connected ecosystems, including vulnerabilities in hardware, embedded software, communication protocols, servers, and web and mobile applications related to IoT devices.

The types of tests conducted on hardware, firmware, and communication protocol depend on the connected device. For example, some devices may require data dumping through electronic components, firmware analysis, or signal capture and analysis.

8. Mobile App Penetration Testing

Mobile application penetration testing is performed on mobile applications (excluding mobile APIs and servers), including both static and dynamic analysis:

• Static analysis extracts source code and metadata and performs reverse engineering to identify weaknesses in application code.
• Dynamic analysis finds application vulnerabilities while the application is running on a device or server.

9. Red Team Penetration Testing

Red team penetration is an advanced testing technique based on military training exercises. It uses an adversarial approach, allowing organizations to challenge their security policies, processes, and plans. Blue teaming, or “defensive security,” involves detecting and withstanding red team attacks and real-life adversaries.

Red teaming combines physical, digital, and social contexts to simulate a comprehensive real-life attack scenario, making it distinct from standard penetration testing. It encompasses tasks related to the various types of penetration testing. While a standard pentest aims to identify as many vulnerabilities as possible in a set timeframe, it is typically limited by artificial restrictions such as the task scope. 

Regular penetration tests are important, but they don’t provide realistic conditions, such as combined attack techniques. Red teaming allows security teams to assess the overall environment and understand how its components function together. It requires critical thinking to identify new, complex vulnerabilities.

Red team assessments are generally more time-consuming than standard penetration tests, often taking several months to complete. This complex nature makes red teaming a rare operation, viable only for large organizations. 

Related content: Read our guide to penetration testing services

Complementing Penetration Testing with Dynamic Application Security Testing (DAST)

Bright Security significantly improves the application security pen-testing progress. By providing a no-false positive, AI powered DAST solution, purpose built for modern development environments the pen-testing process can be automated and vulnerabilities can be found faster and at a lower cost. Moreover, integrating Bright Security into DevOps environments enables you to run DAST scans as part of your CI/CD flows to identify a broad set of known (7,000+ payloads) security vulnerabilities early in the development process. 

In addition to detecting technical vulnerabilities, Bright Security’s unique ability to detect business logic vulnerabilities offers broader coverage and detection that any other automated solution. 

Learn more about the Bright Security DAST Solution

Network penetration testing is an attempt by an ethical hacker to breach an organization’s network without doing harm. The objective is to identify security weaknesses in the network and its security controls, report on them, and allow the organization to remediate them.

Modern networks are extremely complex, with a combination of WAN, LAN, and wireless networks, a large number of endpoints including servers, workstations, mobile devices and internet of things (IoT) devices, and security technologies like firewalls and intrusion prevention systems (IPS). Any of these could be a weak link that allows attackers to penetrate the network. 

A network penetration test takes the perspective of an outside attacker, scanning the network to identify vulnerabilities, and actually exploiting them to prove their possible impact on the business.

In this article:

• Network Security Threats and Attacks
  • Malware
  • Phishing
  • DDoS Attacks
  • Advanced Persistent Threats (APTs)
  • Drive-by Downloads
  • DNS Attack
• External vs. Internal Network Penetration Testing
  • External Penetration Testing
  • Internal Penetration Testing
• Network Penetration Testing Process
  • Reconnaissance
  • Discovery
  • Exploitation
  • Analysis
• Network Penetration Testing with Bright

Network Security Threats and Attacks

Here are some of the common threats that can be tested with network penetration testing.

Malware

Malware is malicious software that can be used to attack computer systems. Trojans, ransomware, and spyware, are common examples of malware. Hackers can use malware to steal or copy sensitive data, block access to files, compromise or damage operational systems and datasets.

Phishing

Phishing is a tactic in which attackers impersonate a reputable entity or individual through email or other forms of communication. Attackers often use phishing emails to distribute malicious links and attachments that can further their goals. These links or attachments typically send the user to a malicious website or directly deploy malware. The end goal of phishing is to extract login credentials, account information, or other sensitive information from victims.

Traditionally most phishing attacks were conducted by email, but attackers are increasingly performing attacks via other forms of communication, including social networks, SMS messages, and even voice calls.

DDoS Attacks

In a distributed denial of service (DDoS) attack, multiple infected computer systems attack a target, denying service for the system’s legitimate users. DDoS can target servers, websites, or other network resources. It is performed by creating a large number of fake connection requests, malformed packets, or other illegitimate traffic that floods a target system and can cause it to slow down, crash, or shut down.

Advanced Persistent Threats (APTs)

An APT is a long-term targeted cyberattack that allows an intruder to gain access to a network and remain undetected for a long period of time. APT attacks are typically aimed at stealing data rather than disrupting the target organization’s network.

The goal of most APT attacks is not to get in and out as quickly as possible, but rather to achieve and maintain continuous access to the target network. Because executing APT attacks can be very labor-intensive and resource-intensive, hackers often choose high-value targets such as countries and large corporations, from which they can steal information over an extended period of time. APT attacks are commonly conducted by large, organized cybercrime groups or state-sponsored hackers.

Drive-by Downloads

In a drive-by download attack, malware is accidentally downloaded to a user’s computer or mobile device, leaving them vulnerable to cyberattacks. This attack is especially severe because the user does not need to click anything or open a malicious email attachment to get infected, and so it can affect even security conscious individuals.

Drive-by downloads exploit vulnerabilities in applications, operating systems, or web browsers (these may be zero day vulnerabilities not yet addressed by the vendor, or known vulnerabilities where the user or the organization failed to apply a security update).

DNS Attack

A DNS attack is a vulnerability that could allow an attacker to exploit Domain Name System (DNS) vulnerabilities.

Although DNS is very powerful, it is designed for ease of use, not security. There are many types of DNS attacks in use today. Some attacks manipulate communication between a DNS client and server. Others use stolen credentials to log into your DNS provider’s website and redirect DNS records to malicious websites.

External vs. Internal Network Penetration Testing

External Penetration Testing

Traditionally, external threats were often considered more important than internal threats. Most organizations agree that anything exposed to the Internet needs some form of security testing, and possibly the most rigorous type of testing is penetration testing. 

If an external host is compromised, it can lead to an attacker digging deeper into the internal environment. If an external device is the target of an attack, like a hacker looking for a public-facing SFTP/FTP server that stores client data, these devices must also be protected. 

External network penetration testing focuses on the perimeter of your network and identifies any deficiencies that exist in public-facing security controls. When performing external penetration testing, the testers mimic real scenarios as best as possible to identify as many potential vulnerabilities as possible. 

External network penetration testing techniques include the following:

• Host and service discover, port scanning and querying
• Attempting to gain access to public-facing systems using default passwords, brute force, password cracking, or other techniques
• Network sniffing and traffic monitoring
• Spoofing or deceiving servers and network equipment
• Using buffer overflow or similar attacks for remote code execution
• Running exploits for discovered vulnerabilities
• Changing configuration of running systems
• Denial of Service (DoS)
• Privilege escalation and lateral movement when gaining access to any internal systems

Internal Penetration Testing

Insider threats are a growing concern at most organizations. An insider threat could be a disgruntled worker, previously terminated employees, or someone trying to steal trade secrets. An insider threat could also be someone who does not have malicious intent—for example, negligent or careless employees, human errors and misconfigurations can all result in a network compromise. 

Internal network penetration testing targets the networked environment that lies behind public-facing devices. This type of penetration test is designed to identify and exploit issues that can be discovered by an attacker who has gained access to your internal network. 

Internal penetration testing techniques include:

• Scanning for internal subnets, domain servers, file servers, printers, switches
• Privilege escalation and lateral movement
• Identifying vulnerable devices, services, or operating systems on the local network
• Deploying malware such as trojans and rootkits to gain persistent access

Related content: Read our guide to penetration testing services

Network Penetration Testing Process

Network penetration testing typically follows four stages: reconnaissance, discovery, exploitation, and analysis. The following discussion mainly refers to external penetration testing, but the process for internal testing is similar.

Reconnaissance

The reconnaissance stage involves scanning systems and uncovering potential weaknesses and vulnerabilities, like an external attacker would do. This has two aspects:

• Technology vulnerabilities—the penetration tester looks for weaknesses in network ports, peripherals, software, or network services hackers can use to get into your systems. This process is very useful for vulnerability assessment and provides an external perspective on security weaknesses in the environment.
• Human vulnerabilities—social engineering vulnerabilities include common phishing scams and theft of login credentials. Penetration testers can try these tactics and see if the company’s employees are vulnerable to social engineering. This can help identify problems and raise awareness of security policies among employees.

Discovery

During the discovery phase, penetration testers use information from the reconnaissance phase to perform real-time testing using pre-coded or customized scripts to identify possible security issues and see if they are easily exploitable. The objective is to identify the possible attack vectors and decide which one the tester will use during exploitation.

Exploitation

In the exploit phase, penetration testers use the information obtained in the discovery phase, such as vulnerabilities and entry points, to begin testing exploits on vulnerabilities they discovered in network devices or IT systems. The goal of the exploit phase is to break into the network environment, evade detection, and demonstrate a capability to do damage (for example, by gaining access to sensitive data).

Analysis

At the end of the test, the penetration tester documents their process and findings, and prepares a penetration test report. In most cases, reports include vulnerabilities identified and exploited, sensitive data accessed, and how long ethical hackers managed to avoid detection.

The report must provide actionable information that can allow the organization to patch vulnerabilities and protect against future attacks.

Related content: Read our guide to penetration testing report

Complementing Penetration Testing with Dynamic Application Security Testing (DAST)

Bright Security enables organizations to automate black box testing for a long list of vulnerabilities across both applications and APIs. These tests include both technical vulnerabilities and business logic vulnerabilities. This combination goes a long way towards providing unparalleled coverage that previously could only be achieved by conducting manual penetration testing. 

Moreover, the automated solution enables organizations to run targeted scans early in the SDLC and remediate issues before they make it to production. This is far superior to having to detect vulnerabilities in a production environment with manual tests. 

Learn more about automated network testing with Bright Security

What Is Web Application Security?

Web application security is the practice of detecting and preventing cyber attacks on websites, and more importantly—building websites that are secure to begin with. This includes a set of security controls built into web applications to protect them from a growing variety of cyber threats.

Web applications inevitably contain bugs and misconfigurations, and some of these are security vulnerabilities that can be exploited by attackers. Web application security helps address these vulnerabilities by leveraging secure development practices, implementing security testing throughout the software development lifecycle (SDLC), resolving design-level defects and avoiding security concerns during deployment and runtime.

This is part of an extensive series of guides about cybersecurity.

In this article:

• Why is Web Security Testing Important?
• Top Web Application Security Risks
  • Injection
  • Denial of Service (DoS) and Distributed Denial-of-Service (DDoS)
  • Cross-site Request Forgery (CSRF)
  • Cross-Site Scripting (XSS)
  • Security Misconfiguration
  • XML External Entities (XXE)
  • Vulnerable Deserialization
• Tools You Can Use to Defend Against Web Application Threats
• 6 Web Application Security Best Practices
• Securing Web Applications with Bright Security

Why is Web Security Testing Important?

Web security testing focuses on identifying security vulnerabilities in web applications and their configurations. Its primary objective is the application layer. Testing web application security often involves delivering various input types to provoke errors and cause unexpected system behavior. These “negative tests” investigate whether the system is performing tasks it isn’t designed to execute.

Additionally, web security testing extends beyond evaluating the security features, such as authentication and authorization, implemented in the application. It’s equally significant to test other features for secure implementation, for example—business logic, proper input validation, and output encoding.

Learn more in our detailed guide to web application security testing.

Top Web Application Security Risks 

Here are some of the major risks facing web applications today.

Injection 

This security risk occurs when untrusted data is sent to an interpreter via a command or query. An attacker injects malicious code that looks like normal code, and can trick the interpreter into executing unexpected commands or accessing data without proper permissions.

An injection attack on a web application can bypass authorization mechanisms, resulting in exposure of valuable data or complete compromise of the system. Common injection flaws include LDAP, NoSQL, and SQL injection.

Learn more in our detailed guides to:

• Code injection
• SQL injection

Denial of Service (DoS) and Distributed Denial-of-Service (DDoS)

In a DoS attack, attackers generate fake traffic through different vectors to overload the target server or surrounding infrastructure. If the server cannot handle incoming requests efficiently, it slows down and eventually refuses to process incoming requests from legitimate users. A DDoS attack is the same thing at a much larger scale, leveraging botnets of thousands or millions of devices controlled by the attacker.

Related content: Read our guide to security testing tools.

Cross-site Request Forgery (CSRF)

CSRF tricks victims into making unwanted requests, leveraging existing authentication. An attacker can use the user’s account privileges to impersonate the user and perform operations on their behalf.

If a user account is compromised, an attacker can steal, destroy, or modify sensitive information. Attackers typically target accounts with high privileges, such as accounts belonging to administrators or executives.

Related content: Read our guide to web application attacks.

Cross-Site Scripting (XSS) 

XSS allows hackers to inject client-side scripts into web pages to intercept user session access, impersonate users, access sensitive information, tamper with websites, or redirect URLs to malicious websites. This flaw occurs whenever an application embeds untrusted data in a web page, or updates a website with user inputs via browser-generated HTML or JavaScript, without proper validation.

Learn more in our detailed guide to web application vulnerabilities.

Security Misconfiguration

This is one of the most common risks to web applications. It occurs when security controls are not set correctly in a web application or the surrounding infrastructure. 

For example, security configuration errors can be unpatched known vulnerabilities, cloud storage exposed to the Internet with no authentication, insecure default configurations left as-is, misconfigured HTTP headers, or unnecessarily detailed error messages that divulge sensitive information to attackers.

Application security professionals must ensure the secure configuration of all applications, frameworks, operating systems, and libraries. It is important to ensure that these are also updated and patched in a timely manner.

Learn more in our detailed guide to websocket security.

XML External Entities (XXE) 

Many web applications have misconfigured XML processors, which evaluate external entity references in XML files. An attacker can exploit external entities to expose internal server files, perform internal port scanning, use a web server for denial of service (DoS) attacks, and perform remote code execution.

Learn more in our detailed guide to XXE

Vulnerable Deserialization

Deserialization is the process of recreating data objects from a stream of bytes. Insecure deserialization occurs when untrusted code, created by an attacker, exploits vulnerabilities in the programming language’s deserialization mechanisms. In severe cases, this can enable remote code execution (RCE). Even if the vulnerability does not lead to RCE, it might still be exploited to perform escalation of privileges, code injection attacks, and replay attacks.

Learn more in our detailed guide to deserialization

Tools You Can Use to Defend Against Web Application Threats

There are two main methods to defend against web application vulnerabilities—prevention or blocking. Ideally, organizations should employ both methods.

Here are key tools to help prevent web application vulnerabilities:

1. Static application security tests (SAST)—involves analyzing the application source code during development. SAST tools help detect coding and design issues that can lead to vulnerabilities. Learn more in our guide to SAST
2. Software composition analysis (SCA)—involves analyzing applications to identify open source software (OSS) and third-party components containing known vulnerabilities or licensing restrictions. 
3. Interactive application security testing (IAST)—involves observing application behavior, such as input, output, data flow, and logic. It requires deploying an IAST agent in the application to conduct a runtime analysis of the code, data flow, and memory. 
4. Dynamic application security tests (DAST)—involves analyzing code in runtime, including servers and underlying application frameworks. It requires a manual configuration of the DAST for each application. Learn more in our guide to DAST

Here are key tools to help block web application attacks:

5. Web application firewall (WAF)—protects web applications against malicious HTTP traffic. It places a filter barrier between attackers and the targeted server to block attacks such as SQL injection, CSRF, and XSS. 
6. Runtime application self-protection (RASP)—detects and blocks attacks by employing in-application instrumentation. You can use an SDK to integrate RASP directly into your codebase or deploy an agent to the host at runtime. 

Related content: Read our guide to microservices security.

6 Web Application Security Best Practices

1. Execute Input Validation

Effectively validating user inputs is crucial for mitigating web application security threats like SQL injection and cross-site scripting (XSS). Verify all data submitted to your application for type, length, format, and range before processing to prevent attackers from injecting malicious code into your system.

Related content: Read our guide to web application attacks.

2. Employ Up-to-Date Encryption

Implementing Transport Layer Security (TLS) with the latest recommended cipher suites and protocols is essential for secure data transmission. Keep TLS configurations current to maintain robust encryption standards.

In addition to TLS for data transmission, securely storing user passwords is important. Use strong cryptographic hash functions like SHA-256 or SHA-512 for password encryption before adding them to your database.

3. Enhance Authentication and Authorization

Implement advanced authentication methods like multi-factor authentication (MFA) to ensure authorized access to your web applications. Set complex password requirements and limit failed login attempts to safeguard against brute force attacks. Implement role-based access control (RBAC) mechanisms to provide the appropriate permissions based on users’ roles within the organization.

Learn more in our detailed guide to web application scanning.

4. Track API Usage

APIs are essential in modern web applications but may introduce security vulnerabilities if improperly managed. Ensure all APIs used in your application have adequate authentication and authorization measures and communicate through encrypted channels. Monitor API usage routinely and analyze access logs for unusual activity or potential vulnerabilities.

5. Record Code Changes

Maintaining accurate records of code changes is crucial for monitoring updates, bug fixes, and new features in your web application. This practice fosters transparency within development teams and helps swiftly identify potential security problems caused by recent modifications. Use version control systems like Git to enable efficient developer collaboration while maintaining a structured history of code adjustments.

Related content: Read our guide to websocket security.

6. Employ Dynamic Testing for Application Security Validation

Using dynamic testing with tools like DAST is another best practice for web application security. Dynamic testing tools can detect numerous issues such as injection attacks, cross-site scripting (XSS), broken authentication and session management, insecure direct object references, and more. Incorporate DAST into all development lifecycle stages, from early testing and staging to production, for shifting security left.

Learn more about SAST in our detailed guide to snyk cli.

Securing Web Applications with Bright Security

Bright is a developer-first Dynamic Application Security Testing (DAST) scanner that can test your applications and APIs (SOAP, REST, GraphQL), enabling you to bake security testing across your development and CI/CD pipelines. 

Detect the OWASP (API) Top 10, Mtre 25 and more, including Business Logic Vulnerabilities. You can easily reduce your security and technical debt by scanning early and often, on every build, to be secure by design. 

Learn more in our detailed guide to mobile security.

With NO false positives, there is no need for manual validation of security findings, removing costly and time consuming human bottlenecks that cripple your rapid releases and drain your security team’s limited resources. 

See Additional Guides on Key Cybersecurity Topics

Together with our content partners, we have authored in-depth guides on several other topics that can also be useful as you explore the world of cybersecurity.

API Security

Authored by Radware

•  API Security: REST vs. SOAP vs. GraphQL & 8 Best Practices 
•  Server-Side Request Forgery: Impact, Examples & Defenses 
•  API attack 

disaster recovery

Authored by Cloudian

• What Is Disaster Recovery? – Features and Best Practices
• What Is BCDR? Business Continuity and Disaster Recovery Guide
• Disaster Recovery Plan: 4 Examples & 10 Things You Must Include

XSS

Authored by Bright Security

• What is XSS? Impact, Types, and Prevention
• Reflected XSS: Examples, Testing, and Prevention
• How DOM Based XSS Attacks work

Security should be a crucial part of any application you are working on. In this article we are going to cover the web application security best practices you should consider when working on your next project, but before we do that, let us quickly cover why security is so important:

Why is it so crucial to have strong application security?

Loss of customer data

Customers trust you with their data. It’s your responsibility to keep that data secure from malicious users and attackers.

Loss of revenue

Service outages and downtime can cost your business a lot of money, let alone the reputational damage that as a result of a breach. How much depends on the business – imagine an ecommerce store being down for hours or days due to a breach.

Loss of customer trust

Customers are more cautious about their data and where it is shared. Losing customers’ data due to a cybersecurity breach can be devastating both to the brand image and customer trust. Loss of customers’ data can in some cases even lead to a shutdown of the business.

Compliance and penalties

Governments are imposing security standards such as GDPR, HIPAA, PCI and ISO 27001 to make sure companies don’t get away with neglecting security. Having your company not comply with those standards can result in fines, penalties or lawsuits.

In this article, we’ll cover the following web application security best practices:

1. Full-scale security audit
2. Encrypt data
3. Real time security monitoring
4. Proper logging practices
5. Implement security hardening measures
6. Regular vulnerability scans and updates

1. Full-scale security audit

One of the best ways to ensure there are no security loopholes in your web applications is to have regular security audits.

A security audit can include one or more of the following:

• Black box security audit: this is the ‘hacker approach’. The application is tested for exploitable vulnerabilities without access to the source code.
• White box security audit: opposite to black box security audits, in a white box security audit you or the team performing the audit have access to information including the code base. This type of a security audit ensures you are following all the best practices, starting with secure coding practices.
• Grey box security audit: as the name suggests, this is a mix approach of white box and black box security audits. In this approach some important information is shared before the audit.

If there are any vulnerabilities detected after your audit, the best approach is to categorise them by their impact, prioritise their remediation and start fixing them with the highest impact vulnerabilities first (Critical / High).

2. Encrypt data

Visitors and customers could share sensitive information on your website. The data in transit between the visitor’s browser and your server has to be encrypted.

Encrypting the data in transit does not only help with customer trust, but also plays an important role in SEO ranking. Search engines like Google prefer websites with SSL. The use of HTTPS is even a ranking factor for Google.

However, it’s not only the data in transport that has to be encrypted. You also have to encrypt the data in rest to make sure malicious actors can’t just copy or destroy it. Follow these practices to make sure your data is secure:

• Implement network firewalls. That will help prevent threats from within the network
• Chose a strong encryption algorithm and encrypt the data before you store it
• Store data on a separate server in a password-protected database
• Infrastructure security is important. Don’t neglect it and invest in infrastructure security

3. Real time security monitoring

We already mentioned the importance of regular security audits, but those will not be enough without a robust real time monitoring. Consider using a web application firewall (WAF) which will help you block any malicious activity in real time.

As web application firewalls can indicate false positive events or miss some threats, consider using ASMP or RASP in addition.

An Application Security Management Platform (ASMP) monitors protocols beyond the application layer and helps you protect your apps against unknown threats in real time. While ASMP is embedded into your app, RASP runs on your server and monitors the behavior of your web applications and context of user input. If RASP detects suspicious activity, it will immediately terminate the session and block the malicious user. Please keep in mind that neither of those guarantees 100% success.

4. Proper logging practices

To have a good insight into events in your app, like what happened at white time, was there something else happening at the same time and how that affected a situation that occurred, you need to have proper logging in place. While this is important information to continually have and monitor, it’s especially important in case of a security incident.

Post-incident forensics can become a daunting task without proper logging in place. On the other hand, with a proper logging mechanism, the task of analysing the cause and understanding the bad actor in case of a data breach becomes much easier.

5. Implement security hardening measures

Default settings won’t be enough for some components and will need security hardening measures, such as:

• Maximum script execution time: Set the maximum time a particular script can run on the server. A low number here could help narrow the attack possibilities. Define the maximum script execution time by your application’s use case.
• Disable modules: Are there modules and extensions on your server that are not in use by the application? Disable them.
• Have a content security policy in place: a good content security policy can help prevent infections like redirection malwares from taking over.

6. Regular vulnerability scans and updates

Hackers are quick when it comes to identifying websites running vulnerable software. Be one step ahead of them by running regular vulnerability scans and identifying vulnerabilities in your web applications or websites before they hit production. This is achieved by implementing automated security testing into your CI/CD pipelines. SAST tools are traditionally implemented earlier into the SDLC, but the results are high in false positives, while requiring a more complex configuration and access to your source code. On the other hand, while traditional DAST tools are language agnostic (they don’t need access to the source code), they are typically used by security professionals and implemented later into the SDLC or used on production. 

Unlike other security testing tools, Bright is built from the ground-up to be developer first, integrated across your pipelines to scan every build / commit as part of your CICD to be secure by design. Easy to use and intuitive, you don’t have to be a security expert to start a scan. With NO false positives, Bright automatically validates every finding so you don’t have to. Thanks to the integration with various ticketing systems, all findings can be easily assigned to different team members for remediation, with developer friendly remediation guidelines for immediate and easy fix at the cheapest, most efficient time.

Sign up for free and see for yourself why Bright is a platform that security teams trust and developers love.

What Is AWS Penetration Testing?

Penetration testing typically involves an ethical hacker looking for network vulnerabilities that a malicious hacker could exploit. These tests provide insights into a network’s points of weakness, informing security teams on how to repair them.

However, Amazon Web Services (AWS) doesn’t always support standard ethical hacking practices, because they may conflict with Amazon policies. Amazon owns the core infrastructure of AWS, so any penetration testing methodologies used on AWS systems are subject to Amazon’s policies.

Pentesting in AWS generally has to address these main areas:

• The external AWS cloud infrastructure 
• The internal AWS cloud infrastructure
• Any applications built or hosted on the platform
• Review of the AWS configuration

In this article:

• The Importance of AWS Pentesting
• Penetration Testing Methodologies for AWS
• AWS Vulnerabilities and Pentest Tools
• Complementing Penetration Testing with DAST

The Importance of AWS Pentesting

As AWS continues to deploy more services and serve millions of additional users, the system becomes exponentially more complex. This added complexity could allow attackers to exploit undiscovered vulnerabilities. The problem only increases if the human factor is also taken into account—any user or administrator who has an identity and access management (IAM) account can be the target of a social engineering attack.

Regular AWS penetration testing is critical for cybersecurity professionals to address these challenges. Penetration testing can help discover misconfigured security groups and excessive privileges, known vulnerabilities in cloud systems, misunderstandings regarding the shared responsibility model which can lead to unintentional risk exposure, failure to implement strong authentication for cloud resources, and lack of employee education with regard to social engineering.

Another aspect of penetration testing is that it can help achieve compliance with regulations such as HIPAA, PCI DSS, and FedRAMP. These and other compliance standards require regular penetration testing to identify, address, and remediate compliance gaps.

Amazon supports penetration testing against its systems, but requires special approval for certain types of tests. Organizations should rely on security experts with the expertise to perform Amazon penetration testing. AWS security partners know what to test and which simulations require Amazon approval.

Penetration Testing Methodologies for AWS

The security testing methodologies of an AWS platform fall into these two categories:

• Security of the cloud—Amazon is responsible for ensuring that the AWS cloud infrastructure is secure. This category includes any vulnerabilities, logic flaws, or zero-day threats on AWS servers that may impact their performance or damage users.
• Security in the cloud—the customers are responsible for ensuring that the assets and applications they deploy on the AWS platform are secure. Organizations must follow the required security procedures to enhance the security of their applications in the AWS cloud.

AWS allows security testing for user-operated services, including cloud offerings that the user creates and configures. Organizations can test their AWS EC2 instances, for example, without incorporating tactics that might disrupt business continuity (e.g., launching a DoS attack).

AWS restricted security testing for vendor-operated services, including any cloud offering that a third-party vendor owns or manages. AWS allows users to pentest the cloud environment configuration and implementation, but not the hosting infrastructure. For example, customers can perform penetration tests for the configuration of AWS services like API Gateway and Cloudfront, but they can’t touch the underlying infrastructure.

One AWS service that supports penetration testing is Elastic Cloud Computing (EC2). The following areas of AWS EC2 instances are open to pentesting:

• The API 
• Customer-hosted mobile and web applications
• The application server 
• The stack associated with an application 
• Virtual machines (VMs) 
• Operating systems

Organizations traditionally use pentesting in on-premise environments or infrastructure-as-a-service (IaaS) offerings. AWS has many software-as-a-service (SaaS) offerings that don’t allow the customer to perform penetration tests because Amazon owns the environment. However, customers can use a black box or security audit to test the identity and configuration of a SaaS service. 

Other areas of the AWS cloud that don’t allow pentesting for legal or technological reasons include:

• Applications and services owned by AWS (including SaaS offerings)
• Third-party EC2 environments owned by another vendor or partner
• Any underlying infrastructure or physical hardware owned by AWS
• Micro or small AWS Relational Database Service (RDS)
• Third-party security appliances managed by another vendor (unless the customer has permission)

AWS Vulnerabilities and Pentest Tools

Several vulnerabilities specifically affect AWS systems, although some are more common than others. Some of the top vulnerabilities of the AWS architecture include:

•   Permissions and configuration flaws—for example, in S3 bucket policies.
•   Compromised credentials—for example, identity access management (IAM) keys.
•   Cloudfront or WAF misconfigurations—enable attackers to bypass security measures.
•   Lambda backdoor functions—enable private cloud access.
•   Cloudtrail log obfuscation—covers an attacker’s tracks. 

It is important to understand the approach and capabilities of a pentest provider. Choosing the right provider allows organizations to leverage end deliverables to identify and prioritize business risks so their teams can take action. 

Related content: Read our guide to penetration testing services

Many independent and off-the-shelf tools are uniquely developed for cloud environments and help organizations understand AWS flaws and misconfigurations. Basic tools for identifying basic vulnerabilities include:

The following basic tools can also help identify basic flaws:

• AWS Inspector—designed to secure applications deployed on AWS.
• BucketHead—from Rhino Security Lab, identifies misconfigured S3 Buckets.
• Nmap—discovers networks and enumerates services.

Basic tests using free tools can be a good start for addressing low-hanging fruit, but they don’t provide extensive protection against vulnerabilities and other business risks. Third-party security providers can offer the expertise and experience necessary to conduct comprehensive AWS security assessments and strengthen an organization’s security posture.

Related content: Read our guide to penetration testing tools 

Complementing Penetration Testing with Dynamic Application Security Testing (DAST)

Penetration testing is valuable to ensure your applications and network are secure, however a large proportion of each is conducted manually by specialist penetration testers. The penetration process takes time, is not scalable and the costs can spiral.

With more companies now apopting DevOps and CICD, further automation of security testing is required that removes security related bottlenecks and provides a direct and immediate feedback loop to developers.

Bright Security’s developer focused Dynamic Application Security Testing scanner is used by penetration testing companies to carry out preliminary scans on their client applications and APIs. You can integrate Bright into your development pipelines to benefit from continual, scalable security testing early and often, on every build / commit. 

Bright automatically validates every security issue, so has NO false positives. This removes the need for you to manually validate security issues (one of the services performed by PT / PTaaS). Coupled with the ability to detect Business Logic Vulnerabilities with Bright, this reduces your reliance on and cost of your manual penetration testing or PTaaS.

Sign up for a FREE Bright account and start automating your application and API security testing

What is SQL Injection and Can it Happen in an Oracle Database?

Unfortunately, the quick answer is a resounding YES – Oracle databases are by no means immune to these attacks.

SQL injections represent one of the most prominent and dangerous attacks, a staple inclusion in the OWASP Top 10. It is a code injection technique used to exploit vulnerabilities in the application layer to retrieve or corrupt the data they hold. 

One example is when a required user’s input is either incorrectly filtered, or the user’s input is not strongly typed and unexpectedly executed or the user gives an SQL statement instead.

While SQL injections are known predominantly as a website attack vector, they are also used to attack any SQL database. 

Security of your applications that use Oracle databases is imperative to secure your data and reputation, especially as attackers have multiple automated tools at their fingertips to facilitate an SQL attack.  Below are some tips on how to protect your web apps.

Using MongoDB…? Read more about SQL injection in MongoDB 

Examples of SQL Injection in Oracle

Attackers carrying out SQL injection attacks in Oracle will generally try to minimize the number of database calls in order to maximize their chances of success. 

One of the most popular tools used to carry out SQL injection in Oracle is an open-source tool called BSQL Hacker, used to discover exploits in the target web application. Some of the things that BSQL Hacker does include:

• fingerprint database version, user details, and permission
• changing attacker’s permissions to database admin
• obtaining available data from the database

One of the safest ways to defend from SQL Injection is to never, ever concatenate user input into your SQL queries. These inputs should always – and by always we mean without exception – be bound into the statement. As soon as you allow the end-user to input the code into your SQL statements, it’s as if you gave them the key to your apps. To carry out an SQL injection attack, an attacker must first find vulnerable user inputs within the web page or application and then input content, namely malicious SQL commands, which are in turn executed in the database. Successful attacks can gain total control over the affected database.

Although they have devastating repercussions and widespread awareness, SQL injections remain commonplace, with most web applications remaining vulnerable in production.

It is crucial to understand how to prevent SQL injection attacks and hackers from breaching your databases.

How to Prevent SQL Injection in Oracle

SQL injection can be prevented using proper programming techniques and robust testing as part of your development pipeline. Here are some tips that could help you to prevent SQL injection in Oracle and keep your application protected:

1. Input Validation 

You must take precautionary measures in order to ensure that the attacker cannot inject malicious code via forms that go out directly towards the database. This is the most common issue as the developers are unaware of the fact that loose input validation could result in catastrophic consequences. What you should at least do is limit the number of characters a user can send into a form field. So, in case you have a “first name” field, it should never contain more than 32 characters. 

2. Minimum Permissions 

Another useful tip is to only grant minimum permissions possible to the end user. This means limiting their ability to edit content on your website as much as you can, because it ultimately means that you’re protected from the attacker potentially taking over as an admin on your website. 

3. Static Statements

What you should also be doing when writing queries and such is to try to always use static statements, where the attacker cannot inject dynamic content that changes your website. As an additional step in securing your web application, make sure that you’re binding variables whenever you can, given that it provides an extra layer of security. 

4. Encrypt Confidential Data

Encrypting the most important and confidential data makes sure that you add an extra layer of protection that might just make a key difference for your web app. Thus, you ought to do this whenever possible since it’s the most popular protection method ever since security took its place in modern IT.

5. Blacklisting

This one is pretty simple, yet extremely efficient in preventing malicious codes from entering your web apps. You can create a list of characters that a user cannot send via input forms, such as “<>/?*()&”, or even malicious statements like “SELECT”, which is automatically limiting the scope of vulnerability on your website. 

Detecting SQL Injection in Oracle

Securing your applications is crucial nowadays. The data has never been more important and sensitive, which also means that the attackers are getting smarter by the day. 

This is why Bright Security’s developer-focused approach allows for non-security-minded developers to scan their applications and find all about potential vulnerabilities. In fact, you can sign up for a free account now in order to scan your applications and ensure that you avoid SQL injection and all other sorts of attacks on your apps. 

Conclusion

Hopefully this article sheds some light on the threat of SQL injection in your Oracle database. Security of your applications should never be taken for granted, which is why checking and testing for security is now a part of our everyday work as developers.

What is Cross Site Request Forgery (CSRF)?

A CSRF attack can force a user to perform unwanted actions on a web application. CSRF assumes that the user is already authenticated. Attackers typically use social engineering to trick users into clicking a link that performs actions that can benefit the attacker.

For example, on an eCommerce website, the attacker can cause the user to inadvertently make a purchase. On a bank website, the attacker can cause the user to transfer funds. If the user has administrative access to a web application, CSRF can be used to compromise the entire application.

In this article:

• How CSRF Attacks Work
• 6 CSRF Protection Best Practices
  • 1. Same-Site Cookies
  • 2. CSRF Tokens
  • 3. Addition Authentication for Sensitive Actions
  • 4. Login CSRF
  • 5. Representational State Transfer (REST)
  • 6. Web Application Security Testing
• CSRF Protection with Bright

How CSRF Attacks Work

A website consists of client-side code, typically written in HTML and JavaScript, and server-side code, which depends on the framework used to build the website. Client-side code allows users to perform actions like navigating to different URLs, submitting HTML forms, and triggering AJAX requests via JavaScript. The server-side code intercepts the data sent in the HTTP request and handles it appropriately.

These server-side actions can also be triggered by forged HTTP requests, unless you explicitly protect them. CSRF attacks occur when a malicious attacker tricks the victim into clicking on a link or executing code that triggers a forged request. The malicious code is hosted on another domain controlled by the attacker, therefore the attack is known as “cross site” request forgery.

To protect yourself from CSRF, you need to do two things. Make sure your GET requests have no side effects, and only allow non-GET requests from your client code.

6 CSRF Protection Best Practices

1. Use Same-Site Cookies

CSRF attacks are only viable because cookies are sent with any requests sent to an origin related to that cookie. You can create a flag for a cookie, which converts it into a same-site cookie. 

Threat actors can send a same-site cookie only if a user made a request from the cookie’s origin. However, it is not possible when a request is made across domains. The request source and the cookie have the same origin if the following conditions are met:

• They have the same protocol and host, but they do not share the same IP address.
• When applicable, they can also share the same port. 

Not all browsers support same-site cookies (see a full compatibility chart), and a same-site cookie will default to a regular cookie when a visitor uses an older browser. It means same-site cookies are more suited as an added layer of defense, and you should only use them with other CSRF security mechanisms. 

2. Use CSRF Tokens

A popular approach to stop CSRF is using a challenge token. A challenge token is connected with a specific user and is sent as a concealed value in all state-changing forms via the web application. This token is an anti-CSRF token, also known as a synchronizer token.

Here is how the anti-CSRF token works:  

• The web server creates a token and retains it
• The token is statically created as a concealed field of the form 
• The user submits the form
• The token is a part of the POST request information
• The application compares the token created and stored by the application with the token transferred in the request
• If these tokens are the same, the request is validated
• If these tokens are different, the request is rejected 

This CSRF protection approach is known as the synchronizer token pattern. It secures the form from CSRF attacks because a cybercriminal also has to guess the token to trick a target into creating a valid request. Attackers cannot readily guess the token, and they cannot create it according to a predictable pattern. To improve protection, invalidate the token after a timeout period, or every time the user logs out. 

Anti-CSRF tokens are typically exposed via AJAX – they are sent as request parameters or headers alongside AJAX requests. To be successful, an anti-CSRF mechanism must be cryptographically protected. 

It is also recommended to utilize anti-CSRF options in development frameworks, rather than having developers create their own mechanisms. This reduces mistakes, makes implementation smoother, and in the end improves security. 

3. Require Stronger Authentication for Sensitive Actions

Many websites require a secondary authentication measure or need reconfirmation of login details when a user carries out a sensitive action – for example, on a password reset page. Generally, the user needs to enter their old password before they create a new password.  

This approach protects the user who could remain logged in by accident and minimizes the likelihood of CSRF attacks. 

4. Mitigate Login CSRF

CSRF vulnerabilities can occur on login forms even when users are not logged in. For example, an attacker could employ CSRF to adopt an authenticated identity of the target on an eCommerce site using the attacker’s account. If the victim then enters their credit card details, an attacker could purchase items via the target’s stored credentials. 

You can mitigate login CSRF by establishing pre-sessions that include tokens in the login form.  You can use a pre-session only before a user is verified – do not reuse it after the user is authenticated. Instead, you should destroy the session and create a new one to avoid session fixation attacks. 

If you do not trust subdomains within your master domain in your threat model, it is challenging to mitigate login CSRF. In this case, you can use strict subdomain and path level referrer header verification to mitigate CSRF on login forms.

5. Use Representational State Transfer (REST) Principles

Representational State Transfer (REST) is a set of design principles that assign actions (create, view, update, delete) to various HTTP verbs. Using REST-ful designs helps your site scale and keeps your code clean. REST demands that GET requests are only utilized for viewing resources. 

Maintaining your GET requests side-effect-free will minimize the damage that maliciously created URLs can achieve. Consequently, an attacker has to work harder to create damaging POST requests. 

6. Leverage Web Application Security Testing

After you have effectively resolved a vulnerability in a web application that could enable a CSRF attack, vulnerabilities can still occur later on. These vulnerabilities occur because developers update the application and change its code. 

Given this, it is recommended that you continually test and scan your web applications for any vulnerabilities, including those connected with CSRF attacks. You should use web applications security tools. 

CSRF Protection with Bright Security

Bright helps you automate the detection and remediation of many vulnerabilities including CSRF early in the development process, across web applications and APIs.

By shifting DAST scans left, and integrating them into the SDLC, developers and application security professionals can detect vulnerabilities early, and remediate them before they hit production. Bright completes scans in minutes and achieves zero false positives, by automatically validating every finding. This allows developers to adopt the solution and use it throughout the development lifecycle.

Did you miss our webinar on ‘Avoiding Security Incidents with a Dev-First AppSec Program’?
Don’t worry; it’s available on-demand!

Renowned security expert Ofer Maor and Bright’s CEO Gadi Bashvitz, discuss the importance of proactive security testing as an intrinsic part of a holistic approach to modern application security. Listen in as they will discuss how effective DevSecOps best practices and a Dev-First approach to security testing can avoid incidents further downstream, covering:

• Real world examples where a lack of an effective AppSec program has led to major incidents
• Security challenges for security and development teams and how you can overcome these
• Shifting left – modernizing your security toolkit and processes to meet developers’ changing needs

https://youtu.be/MpFztmysu_k