Let’s face it – whether you are checking your emails, banking online , shopping for new shoes, or doing serious business, there is a very good chance you are doing it through your web browser. Organizations use the convenience web applications bring to get in front of you, but this convenience does not come without a risk.

As more businesses shift to web apps, they are becoming more attractive targets for cyber criminals. So, what can you do to stay one step ahead of bad actors? – Automate. 

In this article we introduce three key features you have to look for when shopping for your AppSec & API testing automation tool:

Integrating early into the SDLC

Development teams have been using automation to streamline manual activities such as build, deployment and functional testing for years now, and it is time security testing joins the mix. 

By integrating automated security validation into the continuous integration/continuous development (CI/CD) pipeline, you can catch vulnerabilities sooner, reducing the potential risk and financial impact.

According to the NIST (the National Institute of Standards and Technologies), 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.

Additionally, the time it takes to fix a security issue once it is discovered has increased. According to Veracode’s “State of Software Security” report the average amount of time to fix a software defect has gone from 59 days ten years ago, to 171 days. Instead of being remediated during the development cycle, the vulnerability would be in production for almost half a year.

Although SAST tools traditionally did a better job at integrating early into the SDLC,  modern DAST tools are catching up and can be integrated as early as the build phase.

Low number of False-positives

We all know the story about the boy who cried wolf.

The tale tells the story of a shepherd boy who repeatedly tricks nearby villagers into thinking a wolf is attacking his town’s flock. When a wolf actually does appear and the boy again calls for help, the villagers believe that it is another false alarm and the sheep are eaten by the wolf.

What if the same happens with application security? With all the false positives and false alarms, you could skip a serious, real vulnerability that could be exploited. Moreover, even if you don’t miss anything, you end up spending hundreds of hours trying to figure out what is real.

It’s crucial you find a tool that returns as few false positives as possible. We at Bright make sure to automatically validate every finding before reporting it to you. That way we ensure you spend the time and resources into remediating real, exploitable vulnerabilities.

Simple usage

One of the problems automation solves is the huge global shortage of security professionals. Having a tool that requires a team of security professionals to work with shouldn’t be mandatory. To see the real benefits of automation, you need a tool that your existing teams will love and know how to use.

Not even the best AppSec Testing tool is useful if your team is not going to use it.

That’s why we at Bright built our tool from the ground up with developers in mind. We made sure developers don’t have to leave the environment they already use and can configure and start a scan with code, but we also made sure our UX is simple enough so that other teams, like QA, will enjoy using it.

Application security testing with Bright

Bright enhances DevSecOps at its core, with a Dev First approach to test your WebApps and APIs

Key features of our technology include:

• Shallow learning curve: to establish a culture of security testing across your pipelines
• Built for Developers: We empower developers to detect and fix vulnerabilities on every build, enabling them to leverage multiple discovery methods to initiative a scan, including:
  • Crawling – for full automation
  • HAR files – generated per build/commit for scope defined testing or by QA Automation
  • OpenAPI (Swagger) files or Postman Collections – to test APIs or Single Page Applications
• Smart Scanning functionality: leveraging sophisticated algorithms to carry out the right tests against the target, removing complexity for developers whilst ensuring scans are automatically optimized to maximize speed and prevent development drag
• Built for Modern Technologies: Microservices, Single Page Applications, APIs (REST, GraphQL) are all supported 
• No False Positives: The only tool with fully automated validation of every vulnerability detected, freeing up valuable time for your security team and saving a considerable amount of money, to release fast and be secure by design
• Seamless Integration: Rest API, CLI for developers, or with common tools such as CircleCI, Jenkins, Jira, GitLab, Github, AzureDevOps and more

Security is no longer a siloed team with sole ownership of security testing – security testing is increasingly shifting left. Instead of developers being brought into the fold later in the process, developer focused security testing tools are bridging the gap between engineering and security.

Automation is key, with those implementing application security testing into their CI/CD pipeline to detect and fix security vulnerabilities on each build or every merge to master, seeing a considerable benefit. 

It’s not a one size fits all, with different types of automated security testing tools required across your pipeline to ship secure applications and APIs, at speed. 

Software Composition Analysis (SCA) and developer-centric DAST enable this and is easily achievable with Snyk and Bright, respectively.

How does developer focused DAST augment  SCA and make you more secure?

Software Composition Analysis (SCA) 

SCA is a widely used form of developer application security testing, with Snyk being amongst the leaders in the field. SCA identifies security vulnerabilities in your 3rd party dependencies, by building the open source dependency trees for your applications and mapping these against a database of known vulnerabilities. It then reports vulnerable open source that has been pulled into your application, to fix or patch accordingly.

The use of open source has grown dramatically over the past few years, with flaws in open source dependencies being more prevalent than ever.

For any organisation using open source, SCA like Snyk’s should definitely be used to achieve a degree of security, but is this enough? 

Dynamic Application Security Testing  (DAST)

Not all developers are familiar with DAST, which is not surprising. Historically DAST solutions were  built for security teams, not developers, and run either by the internal security team or outsourced testing firms on production applications. 

With DevSecOps, these tests need to be conducted much earlier in the development process to get a feedback loop to the developers.

While SCA looks at your source code and dependencies, Bright’s innovative developer-focussed DAST enables developers to detect and fix security bugs that they have introduced – the custom (or 1st party) code. This is done as part of the developer’s workflow or as part of their CI/CD pipeline. 

With Bright, an automated DAST scan can be triggered on every build / commit or PR, to test your runtime applications and underlying APIs (whether REST, SOAP, or GraphQL), detecting vulnerabilities like SQL Injection and Cross-Site Scripting (XSS), for example.

Scans that last minutes and not hours keep up with your rapid release cycles and are not a bottleneck, maintaining DevOps speed.

Having that direct feedback loop to developers means you can fix early and often. Bright’s plug and play integrations with your pipeline are seamless – developers can stay in their environment with Bright’s CLI, as well as integrating with the likes of CircleCI, Jenkins, JFrog, AzureDevOps, JIRA and more.

Whie false positives are notoriously an issue with DAST tools, Bright’s innovative engine automatically validates every finding…no need for manual validation checks, no delays, and no builds failing for no reason! 

New and recurring issues are identified and flagged as such, so focus and prioritisation of remediation is facilitated.

These features mean that there is less of a reliance on manual testing and enables security testing to be placed in the hands of developers.

So…which should you focus on and why?

Snyk & Bright – Holistic Developer-Centric AppSec Testing

To be secure by design and ensure you are shipping secure applications and APIs to production, SCA like Snyk’s, and Bright’s automated DAST should be used in conjunction.

Snyk’s SCA gets you visibility of your open source vulnerabilities that may underpin your applications, that the creative features are built on top of.

Bright’s innovative DAST lets you very easily detect security vulnerabilities across your applications and APIs. Test every build and get results you can trust, with automatically validated results free from false positives and developer friendly remediation advice.

By deploying and leveraging both tools, you are covering all your bases, to find a broader range of vulnerabilities faster and earlier, to fix them…faster and earlier!

The question is not whether you should be using SCA or DAST, but how and when you can start to use them together across your pipelines…the answer is, very easily (see below)!

Get started today

New to Bright and/or Snyk? Try us both for free to start testing for vulnerabilities in your applications today

Sign up for a FREE Bright account here – follow our quick step wizard and be up and scanning in minutes!

Try out Snyk for free here too!

You can learn more about Bright, all our integrations and more on our knowledge base

What are Penetration Testing Services?

Penetration testing (also called pentesting) is a controlled attempt to breach IT systems. Penetration testing is performed on behalf of the organization, in order to discover and remediate security weaknesses. There are two types of penetration testing services: manual and automated.

Manual penetration testing services

Traditionally, organizations contract penetration testing services from ethical hackers or security consulting firms. Manual penetration tests are extensive and methodical, but because of their high cost and complexity, they are performed infrequently, usually once per quarter or even once per year. In addition, manual pentesting can be unpredictable as some testers are very good, and others are not as good so will perform less well.

Automated penetration testing services

A new type of penetration testing service is penetration testing as a service (PTaaS). In this new model, a software as a service (SaaS) platform gives an organization automated tools it can use to perform penetration tests against its own systems. The main benefit of PTaaS is that it is predictable, inexpensive, and enables penetration testing on a continuous basis.

PTaaS can be fully self-service, used by the organization’s security or development teams or it can be delivered in a hybrid model, where the PTaaS provider offers a technological platform, but also helps operate it with its own security experts, guiding penetration testing and recommending remediations.

In this article, you will learn:

• What is Penetration Testing as a Service?
• What are Contract Penetration Testing Services?
• Types of Penetration Testing Services
  • Web Application Penetration Testing
  • Network Penetration Testing
  • API Penetration Testing
  • Mobile Application Penetration Testing

Penetration Testing as a Service (Automated Penetration Testing)

Penetration testing as a service (PTaaS) is performed by utilizing an automated online service, which organizations can use without contracting an external penetration tester.

PTaaS combines manual and automated penetration testing, allowing security teams to identify and fix vulnerabilities faster, better understand security mechanisms, and perform more frequent security testing. Customers use an online interface to manage penetration testing and data, making it easier to define scope of new penetration tests, view test results in real time, and perform continuous testing. 

Benefits of PTaaS services

The main value of PTaaS is that penetration tests can be performed much more frequently. New code and configurations are released daily, and each new version can have new vulnerabilities. With PTaaS, it’s possible to schedule and run a new penetration test for each new release. 

This type of continuous testing proactively improves the security environment, by identifying vulnerabilities, simulating potential attacks, and prioritizing the severity of attack outcomes.

Key features of PTaaS platforms

Here are the most important features potential customers should look at when evaluating an automated penetration testing service:  

• A library of up-to-date recommendations for vulnerability remediation
• Ability for multiple testers to collaborate on the same testing project
• Standard reporting and severity metrics across multiple vulnerability scanners
• Customizable reporting formats
• Long-term tracking of penetration testing activities and remediation of vulnerabilities discovered
• Integration with existing ticketing systems and governance, risk and compliance (GRC)

Related content: read our guide to penetration testing tools

Contract Penetration Testing Services (Manual Penetration Testing)

Unlike PTaaS, traditional penetration testing services are usually contracted to a security firm or individual ethical hacker. This individual or team provides an assessment of potential threats to company systems, in a systematic way, according to a predefined scope. 

Penetration testing starts from the perspective of an outside intruder or malicious insider. Like a real attacker, the pentester performs reconnaissance of the environment, identifies possible exploit paths, and attempts to penetrate the system being tested, without causing damage or exposing sensitive data.

The most important part of a penetration testing service is a final report that provides a list of vulnerabilities discovered during the test, assets or systems related to each vulnerability, an asset-related risk score, and recommendations for mitigating the risk in each of the affected systems.

Key qualifications of penetration testers

A good penetration tester should be:

• Certified in relevant technology systems and compliance standards
• Proficient with IT systems used by your organization
• Experienced with exploit toolkits, and preferably able to customize exploits and malware
• Experienced in social engineering
• Analytical and methodical
• A good communicator, able to provide reports that can communicate vulnerabilities and their impact both to management and technical staff

Types of Penetration Testing Services

Penetration testing services can be applied to several levels of the IT infrastructure. When selecting a penetration testing service, ensure it supports the type of penetration tests your organization needs.

Web Application Penetration Testing

Web application penetration testing looks for weaknesses in data validation and integrity, problems with authentication and session management, and other vulnerabilities. Penetration tests can identify security issues in databases, web application source code, and backend networks.

A web application pentest typically has three phases. Reconnaissance, discovery of security vulnerabilities, and exploiting vulnerabilities, in an attempt to gain unauthorized access to the application or its backend systems.

Learn more in our detailed guide to web application penetration testing

Network Penetration Testing

A network penetration test identifies security weaknesses in network infrastructure, including firewalls, switches, routers, and endpoints like servers and employee workstations. It can help prevent attacks exploiting incorrect firewall configuration, attacks against routers or switches, DNS attacks, proxy attacks, man in the middle (MiTM), and more.

Network penetration testing uses techniques like port scanning, traffic fuzzing, configuration vulnerability testing, virus scanning, and system fingerprinting. 

API Penetration Testing

Application programming interfaces (APIs) play a crucial role in modern information systems. Many IT systems communicate with APIs, or expose APIs, over the public Internet, making APIs a preferred attack vector for many attackers. 

API penetration testing involves learning an API’s structure and commands (some tools can import API commands using standards like OpenAPI), and checking for vulnerabilities like weak authentication, code injection, resource rate limiting, and data exposure. 

Mobile Application Penetration Testing

Many organizations have adopted bring your own device (BYOD) policies, meaning that employee’s personal mobile devices are allowed to connect to the network. Naturally these devices are less secure than corporate devices. 

Mobile penetration testing can test new attack vectors, such as deploying malware through mobile applications or phishing messages sent to personal devices, attacks exploiting weaknesses in WiFi networks, compromise of mobile device management (MDM) protocols, and more.

Penetration Testing Services with Bright

Bright 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 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’s unique ability to detect business logic vulnerabilities offers broader coverage and detection than any other automated solution. 

Learn more about Bright

If you’re anything like me, you’re already thinking about what you might want for Christmas (or Chanukah, or Eid – other High Holy days are available).

Whilst my son is thinking about the latest Nintendo Switch game, I know that you are probably (also) thinking about your ideal security testing tool and the key features it should have.

In today’s fast-paced software development world, with DevOps and CI/CD, the need for security testing automation has never been greater.

To enhance DevSecOps, security testing needs to be performed on every build, or merge to master at best, and on every sprint at least. This requires the adoption of effective AppSec tools that can keep up.

We recently discussed DevSecOps Tooling Best Practices, but if you had to choose one key feature for your DAST tool, what would it be?

What is the most Important Must-Have feature of your DAST Tool?

We ran polls on LinkedIn, Twitter and in a recent webinar, to ask this very question – where do you sit..?

With 67% of respondents choosing “NO False Positives”, the need for accuracy is apparent.

In a world of automation, having false alerts that need to be manually verified is debilitating and unscalable, regardless of the size of your team. With tens, hundreds, thousands of accumulated false positives, a decision needs to be made to stop the release or push to production and take the risk. This compounds the security debt issue, but also leads to a distrust of the tooling and decimates any security culture in your organisation.

Receiving fully validated results in an automated way enables security to understand the risk in a snapshot without wasting critical time on manual validation, whilst being able to quickly prioritise remediation. Additionally, developers trust that their build failed for good reason and not a false alert and that their JIRA (or other ticketing tools) ticket is actionable and not ignored.

Nineteen percent would want their DAST tool to be able to test both web apps and APIs. 

Whether you are still using SOAP, have kept up with the times and using REST, or are pushing the innovation and adopting GraphQL, 90% of all web traffic is carried out over APIs. Traditional / legacy DAST tools either do not support API testing at all, or do so in a convoluted way with various proxies that are cumbersome for security teams, let alone developers. This forces the reliance on slow, expensive manual testing.

A DAST tool that is developer and DevOps friendly came in third place on this poll with 14%, but the importance of this feature cannot be underestimated.

Typically built for the security team, DAST tools are notoriously hard to configure and can be as hard to truly integrate into your pipelines. To shift security testing left and put it into the hands of developers, DAST needs to be intuitive to carry out the right tests against the target, without the need for developers and / or QA to be a cybersecurity expert. This enables them to effectively collaborate together to remediate security bugs, without constantly leaning on an overstretched security team. 

Bright’s DAST automatically validates every vulnerability it detects, producing results that everyone in the pipeline can trust, with No false positives, to test your web apps and APIs (SOAP, REST and GraphQL). 

Uniquely integrating into your SDLC with multiple scan optimisation settings out of the box for developers to start scanning, contact us today to learn how Bright can make your Christmas come early or request a demo.

Whether you are just starting your DevOps journey, or are fine tuning your processes as you mature, with CI/CD and easy deployment of new microservices, changes to applications and APIs are carried out at breakneck speed, with multiple iterations in a day.

Making sure your security testing can keep up with this pace, is key to a successful AppSec programme. 

Development teams that scan for security issues early and often substantially reduce their security debt and technical debt, as discussed in our blog “Size may not matter…but in DevSecOps, frequency certainly does!”.

How often are you testing for Application or API vulnerabilities?

We ran polls on LinkedIn and Twitter to ask this very question – the results of which are below and are rather telling! 

An overwhelming 71% of respondents are testing their applications and APIs either before a major release (39%), typically carried out with manual VA or PT, or are still relying on periodic penetration testing (32%) – monthly at best, or annually.

Whether carried out internally or via a third party, this is a time-consuming, resource-intensive, and expensive process. This also compounds the security debt problem, which further increases your cyber risk. Not to mention that this practice goes completely against the notion of DevOps.

Most legacy Dynamic Application Security Testing (DAST) solutions, used to test applications for security vulnerabilities, lack the ability to test APIs at all (whether REST or GraphQL), which partially explains these results. 

However, it is an accumulation of several limitations in legacy DAST tools that make it even harder to automate the scanning process. Hence the reliance on manual work, namely:

1. Inability to effectively and seamlessly integrate into the SDLC
2. Not developer friendly – built for security professionals
3. Inability to test every pull request, or merge to master due to speed limitations
4. Lack accuracy – many false positives that need manual validation
5. Delayed feedback loop to developers

This lack of automation creates a human bottleneck which is impossible to scale and explains why so few organizations are able to test every build or commit (17%) or every Merge to Master (12%). 

Without automation and relying on siloed security teams, it is also very hard to cement a culture of security, which underpins DevOps.

Having security champions is important to achieve this culture, but they too will face an uphill struggle to succeed with such a fragmented security testing process. A seamless and timely feedback loop of validated security issues, removing the false positives, is needed for developers to fix issues early, to be secure by design and minimise risk. 

Automation of security testing baked across your SDLC, for both WebApps and APIs, is paramount.

A DAST tool that your developers, security champions, QA professionals and security team are able to use is required, so that they can effectively collaborate to fix security bugs. 

The earlier this can be done in your pipeline the better. Add to this integration with your tooling to achieve comprehensive security compliance on every build to enable you to shift security testing left and you have a winning formula. 

Bright’s no-false positive Application Security Testing automation platform helps achieve these goals. Join the 17% of poll respondents and start running security tests on every build – contact us today to learn how our clients are achieving this success or request a demo.

With applications driving the global economy, developers are under pressure to deliver software and more features at an unprecedented scale and speed. 

While no developer wants to create insecure products, most software products are pushed into production with vulnerabilities which stay unremediated causing a spiraling technical and security debt and significant risk for the organization.

Application Security scanning frequency really is the key, with development teams that scan for security issues early and often substantially reducing their security debt. 

But what is Security Debt and how early and how often should you be scanning? 

What is Security Debt?

Security debt is the continuing accumulation of security vulnerabilities in your software that compound to make it harder (read: impossible) to catch up with remediation to secure your applications and data from attacks.

Unlike technical debt, which may get in the way of releasing new features for the needs of the business, the growing pile of security vulnerabilities puts your organization at an increased risk of cyber attack. Indeed, in many cases, Medium to High severity vulnerabilities are being deferred, including issues like XSS, SQLi and others in the OWASP Top 10. According to Forrester, the average time to resolve a high vulnerability in production is 4 months. This means that you could be placing your entire business at risk for 4 months. Unfathomable, right? Yet it happens every day!!!

How is Security Debt caused?

Security debt is caused when security testing is not baked across the software development life cycle (SDLC), accumulating when development releases software without testing for or fixing vulnerabilities. 

With most organizations carrying out periodic (monthly, quarterly, annually?) automated, or manual security testing, they make the decision to release now and fix vulnerabilities later.  This results in an increased risk of exposure until the issues are remediated. The main issue is that ‘later’ keeps on getting pushed back and in many cases, ‘later’ becomes ‘never’, making security debt even worse!

When and how often should you be scanning?

Your Security Debt should be treated just like your Credit Card debt – if you keep spending and don’t pay off your monthly balance, eventually it will lead to bankruptcy.

With the sheer volume of iterations to applications and APIs on a daily basis, security testing needs to mirror this cadence, to prevent a security breach and potential bankruptcy too!

Heavy, periodic scanning and quick remediation over a defined limited period to meet a release deadline, forces you to defer issues and add to your security debt.

DevOps and DevSecOps focus on enabling organizations to detect and fix security vulnerabilities as early and as often as possible in the software development life cycle (SDLC). 

This mindset, where everyone is responsible for security, has broken down the barriers between developers, QA and security, facilitated by security champions who know what good looks like in terms of security.

With the increased velocity of development, comes an accelerated introduction of vulnerabilities. Security testing and remediation needs to become a habitual process and part of your accelerated pipelines. Automation of daily security testing is critical to establishing a cadence of secure software

The advantages of daily scanning are clear to see:

With regular testing on every build / commit, or at least daily, everyone can be focused on making better security decisions as part of a unified DevSecOps strategy to deliver software with speed, efficiency and security.

Relying on manual testing simply cannot keep up with accelerated development timelines. The success of this strategy relies on development teams having easy to use, accurate and seamlessly integrated automated testing technology. 

Traditional legacy Dynamic Application Security Testing (DAST) tools are not built for this regular cadence of security testing that demands speed.

Bright’s innovative Bright technology, with no false positives, has been built with a developer first approach, to enable you to effectively integrate security scanning on every build / commit, to enhance DevSecOps and reduce your security debt. Contact us to learn more and request a demo.

Last week I had the pleasure of presenting at the Pittsburgh Cybersecurity day in partnership with ISACA. It was exciting to see more than 250 cybersecurity and application security professionals interested in discussing and learning how security can be enabled in a world rapidly adopting DevOps practices.

So, why is putting the Sec in DevSecOps so important today?

According to Gartner research, 2020 is the inflection point where more than 50% of organizations will adopt DevOps practices. This adoption is expected to continue at a rate of 20% year over year for the next 5 years. This accelerated DevOps adoption is justified as it offers many advantages including:

• Faster release times
• Higher SW quality
• Reduced failure rates
• Cost savings

However, with all these advantages there are also some disadvantages. First among these is the risk of releasing vulnerable applications and the concern of being hacked. To understand this better, let’s look at an example:

This results in significant vulnerabilities in production as issues are only remediated months after a release is completed!

Now that we understand the problem, where should we focus?

According to the latest Forrester Wave, >70% of security incidents occur at the web layer. With the accelerated adoption of APIs and the less mature threat models for Web Applications and APIs, these risks are continually increasing.

How do you Add the Sec to DevSecOps?

Now that we understand the importance of adding application security into your DevOps environment (adding Sec to DevSecOps), what do you need to do to achieve this?

There are a number of aspects to consider:

• People: Putting the correct organization in place
• Process: Establishing the right processes
• Technology: Implementing solutions that enable you to achieve this

In order to effectively implement DevSecOps an organization needs to share the responsibility (and joy) of security with the development and QA organizations. Due to the increased velocity of development and the ratio between developers and security professionals in the organization (up to 100:1 in many cases), it is impossible to achieve this goal without sharing the ownership for security. You can read more about this in our recent post about security champions and how to create them. 

Once the team is in place you need to make sure you have the correct processes to facilitate effective SecOps. These processes include feedback loops for:

• Defining the correct procedures for ensuring security is timely and effective
• Making sure you have the right coverage
• Identifying vulnerabilities early
• Remediating vulnerabilities when they are identified
• Validating the fixes that were implemented
• Facilitating feedback loops for continuous improvement

To learn more about this, you can follow our blog post about it here: https://brightsec.com/blog/devsecops-tooling-best-practices/

Last but certainly not least, you need to implement the correct technology that will enable the organization to effectively implement DevSecOps. These solutions need to be built from the ground up to enable developers and QA professionals to adopt them and must include these key features:

• Seamless integration into the SDLC
• Making sure scans can complete at the speed of DevOps while effectively identifying vulnerabilities.
• Provide different users with different interfaces that will enable them to adopt solutions as part of their standard workflows and not change their flows.
• Eliminate false positives in an automated manner and don’t delay (and annoy) developers by having them waste hours sifting through false positives. 
• Provide clear and effective remediation guidelines.

Solutions like Bright are specifically built to enable organizations to add the Sec into DevSecOps.

When implemented correctly, organizations can achieve amazing results.

To learn more about effectively implementing DevSecOps please reach out to Bright and speak with our experts

DevOps teams have become successful in releasing code at speed, whether for webapps or APIs, but with the lack of testing automation, are releasing vulnerabilities at speed too.

To achieve DevSecOps, you need to bake security into your rapid-release cycles, requiring the adoption of effective tools and practices, to unify your teams across application development, QA testing, and of course your security teams, under a common DevSecOps methodology.

Below are some key aspects to consider when implementing tooling to your DevSecOps pipelines:

1. ‘Develop’ a Culture of Security…

Not really specific to tooling, but one of the main pillars that is critical to achieving DevSecOps – security culture; once you have management buy-in, it’s about collaboration between your development and security teams, breaking down the silos and creating champions for this change. These champions can serve as the go between that speaks the different languages of the pipeline itself

2. Empowering your teams to scale security testing, at speed

When adopting DevSecOps, you are shifting security testing left, i.e. into the hands of your developers, who need to be the first line of defense, enabling them to detect, prioritise and treat security defects like they do with functional defects, to fix them early.

To do this however, developers need tools they can actually use…not another tool built for security professionals that is going to be disabled and join your other shelfware. For modern development environments, you need a modern DAST with a Dev First security approach, that is simple and intuitive to use where you dont need to be a cyber security expert to configure the tests and understand the output. 

Having a DAST that tests both your WebApps and APIs will give you that single pane of glass, additional buy-in from your teams and longevity, reducing your TCO.

3. Security feedback loop

With scale and speed comes automation, requiring a DAST tool to detect your vulnerabilities early. You need to provide your developers with the ability to scan every build / commit from their dashboard and to then automatically raise tickets with GitHub or Jira for example, into a feedback loop, so that each security player in your team has visibility, from your developers, QA / security team, to the CISO. 

4. Accuracy of and Trust in the Tooling

Having a tool that is easy to use and integrated into your pipeline is great, but if it is setting off false alerts (false positives) and your builds are failing because of these, then your developers will soon make their feelings felt. The results need to be accurate and deliver actionable results with remediation guidelines for your developers to remediate early. The manual validation of vulnerabilities is slow and expensive and so a tool that removes these is essential to maintain the speed of DevOps while delivering security compliance. If you are a CISO, how can you effectively evaluate your risk, on demand, when your results are skewed with these false positives and are draining your internal security team as they scramble to manually validate the findings..?

Achieving DevSecOps with Bright

Bright enhances DevSecOps at its core, with a Dev First approach to test your WebApps and APIs

Key features of our technology include:

• Shallow learning curve: to establish a culture of security testing across your pipelines
• Built for Developers: We empower developers to detect and fix vulnerabilities on every build, enabling them to leverage multiple discovery methods to initiative a scan, including:
  • Crawling – for full automation
  • HAR files – generated per build/commit for scope defined testing or by QA Automation
  • OpenAPI (Swagger) files or Postman Collections – to test APIs or Single Page Applications
• Smart Scanning functionality: leveraging sophisticated algorithms to carry out the right tests against the target, removing complexity for developers whilst ensuring scans are automatically optimised to maximise speed and prevent development drag
• Built for Modern Technologies: Microservices, Single Page Applications, APIs (REST, GraphQL) are all supported 
• 0 (Zero) False Positives: The only tool with fully automated validation of every vulnerability detected, freeing up valuable time for your security team and saving a considerable amount money, to release fast and be secure by design
• Seamless Integration: Rest API, CLI for developers, or with common tools such as CircleCI, Jenkins, Jira, GitLab, Github, AzureDevOps and more

To find out how you can leverage our technology to achieve DevSecOps for your WebApps and APIs, please do get in touch or request a demo here.

Bright’s ability to work with modern technology stacks and API security testing now includes full support for GraphQL APIs, enabling our customers to simplify, automate and scale their security testing even further with our solutions, as they embrace new architectures.

Developed internally by Facebook and released publicly in 2015, the rise in popularity of GraphQL has grown exponentially, and we are excited to support our clients who join the many household names that are embracing GraphQL, including Github, Twitter and Airbnb.

Our GraphQL API security testing support exemplifies our dedication to enabling our clients, at the forefront of modern technology, to integrate application security testing across their CI/CD pipelines and to reduce their reliance on manual testing.

The Rise of GraphQL

What has driven this rise in popularity? Advantages of a GraphQL API include:

Microservices Friendly, just like Bright – GraphQL API handles communication between multiple microservices, merging them into one GraphQL schema, great when migrating from a monolithic application to a microservice architecture.

Single API call, with precise data fetching – Whereas REST APIs lack granular control over data, resulting in the over-fetch or under-fetch of data, GraphQL delivers a modern, simple, efficient and flexible way to improve client-server interactions, by enabling the client to make a single API call to obtain the precise data its needs, maximising performance.

Rapid production iterations – with GraphQL, changes in front end code do not require the restructuring of code by the backend engineers, so frontend developers can promptly respond to user feedback and make the changes.

Eliminates versioning – API evolution with REST results in API versions, however GraphQL eliminates versioning by deprecating APIs on a field level, removing them from the schema without impacting the existing queries. This single, evolving version provides applications with continuous access to new features.

API documentation Automation – Documentation updates are synchronised with API changes. As the GraphQL API is closely coupled with code, once a field, type or query changes, so do the docs, meaning developers spend less time documenting an API, always a good thing!

An innovative API, needs an innovative DAST 

You are at the forefront of technology and have invested in GraphQL for automation, accuracy, superior performance and speed. 

Bright is your security partner with a technology that mirrors these deliverables, with innovative AppSec testing automation built from the ground up with a Dev First approach, to test modern WebApps and APIs as part of your CI/CD.

Supercharge your GraphQL (or REST and SOAP) security testing with Bright. 

Key features of our GraphQL testing include:

We Understand
Unlike any other DAST tools, we automatically parse the data types to understand their context, to leverage sophisticated attacks and analyse the responses to evolve the payloads further.

Full depth parsing
Ability to parse varying interaction definitions, such as an XML object inside a GraphQL query, or vice versa

Sophisticated Payloads
Compliance testing to detect the OWASP API Top 10 and more, or carry out API Fuzz testing with Bright.

CI/CD Integration
Integrate via Rest API, our CLI for developers, or with common tools such as CircleCI, Jenkins, Jira or Github to carry out incremental scanning to empower your developers to detect and fix vulnerabilities on every build as part of your CI/CD, leveraging multiple discovery methods to initiative a security test, including:

• Crawler – proprietary and advanced to detect and parse GraphQL
• HAR files
• OpenAPI (Swagger) files 
• Postman Collections

To find out how you can leverage our technology to test your GraphQL, please be in touch or request a demo here.