The company’s new brand is inspired by its flagship software supply chain solution, Black Duck software composition analysis (SCA), which has helped thousands of organizations around the world adopt open source technology safely and securely for nearly 20 years.

As an independent company, Black Duck provides the full portfolio of application security solutions previously available from the Synopsys Software Integrity Group. Black Duck’s mission is to help organizations build trust in their software by enabling them to manage application security, quality, and compliance risks at the speed their business demands. This empowers Black Duck customers to innovate and transform their businesses with new, emerging technologies like AI.

As a recognized market leader, Black Duck provides a comprehensive, powerful, and trusted portfolio of application security products and services. As a newly independent company with a singular vision and focus, Black Duck is even better positioned to deliver the leading solutions the market has come to expect.

Black Duck’s portfolio, which has been named a Leader in the Gartner Magic Quadrant for Application Security Testing for seven consecutive years, includes:

• Polaris SaaS Platform

• Coverity Static Analysis

• Black Duck SCA

• WhiteHat Continuous Dynamic Analysis

• Seeker Interactive Analysis

• Defensics Protocol Fuzzing

• Security Testing, Consulting, and Audit Services

Veteran security leader Jason Schmitt, who joined Synopsys in 2020 as the general manager of the Software Integrity Group, will continue to lead Black Duck as Chief Executive Officer. Black Duck has appointed Joy Meier as Chief Human Resources Officer and General Counsel. The remainder of the existing Software Integrity Group’s leadership team will continue their roles at Black Duck.

“We’re excited to complete our transition from Synopsys to Black Duck,” said Jason Schmitt, CEO of Black Duck. “I am proud of what we have accomplished to get here, and I am incredibly optimistic about our future as an independent company. With our broad portfolio of application security solutions underpinned by differentiated technology and a talented team of experts, we enter the next phase of our journey with momentum and a renewed focus to help our customers build trust in their software.”

The post Synopsys Software Integrity Group rebrands as Black Duck Software appeared first on SD Times.

According to the company’s announcement, fAST Dynamic is built upon scanning technology Synopsys acquired from WhiteHat Security, and adds on to fAST Static and fAST SCA, which were built into the company’s Polaris platform last year. This allows users to deal with vulnerabilities in their own code, open-source dependencies and application behaviors in one solution.

“Dynamic analysis is an essential technology for securing modern web applications, but legacy DAST tools can be too slow and difficult to use in fast-paced development environments,” said Jason Schmitt, general manager of the Synopsys Software Integrity Group. “With fAST Dynamic, we have evolved the powerful and accurate scanning technology from Whitehat Security to create a solution designed for the speed of modern development. Synopsys fAST Dynamic enables DevOps teams to scan their applications quickly and accurately, eliminating the need for time-consuming configuration and triage efforts which are often required with legacy tools. With the addition of fAST Dynamic, Polaris customers can orchestrate rapid static, SCA, and dynamic scans through a unified SaaS platform, enabling them to simplify and accelerate their DevSecOps workflows.”

Among the features Synopsys has introduced with fAST Dynamic are:

• Simplified onboarding and configuration
• Smart attack execution, offering the ability to navigate and analyze web applications to ensure comprehensive test coverage
• An optimized analysis engine that targets critical and high-impact vulnerabilities and minimizes false positives and which can be integrated into organizations’ CI/CD pipelines

Synopsys fAST Dynamic will be available in April on the Polaris platform. To learn more, read the blog post. 

The post Synopsys releases fAST Dynamic test solution appeared first on SD Times.

The COSO’s function is to monitor and advise corporate finance on the use of open source within the organization. Yet, until recently, searches for people who actually use the COSO title yielded few results.  

The main reason developers are grabbing open-source components and libraries is because of the pressure on them to deliver software faster. According to Javier Perez, chief open source evangelist and senior director of product management at software company Perforce,  developers know that if something has already been written, it will save them hours of work. If that piece of code comes from a company-supported project, or one that has a large community of contributors, it’s probably the most recent version and it’s likely to be secure. But, he noted, “There is still a lot of open source out there that has one or two or three guys working on it, but I think it just shifts the bottleneck from upfront, where it would take longer to write the code securely yourself, and just moves it down the line. Now we have to test it longer. This is the age-old argument of, are you sacrificing quality for speed? Are you sacrificing speed for quality?”

Few developers start from scratch anymore, Perez pointed out. “Everyone takes packages, and they don’t even know what they’re getting with the dozens or hundreds of packages they’re using for a specific library. Remember, open source is built with other open source, which is built for another open source … and that’s the full software supply chain.”

This creates challenges for software testers as well as security teams. Open source comes with dependencies upon dependencies, so tools such as software composition analysis and SAST and DAST give organizations insights into what vulnerabilities might exist in the code. And the chief open source officer can be on top of the teams to make sure they’re using the latest versions of the open-source software and ensure that they’re uploading fixes that erase vulnerabilities.

Further, a COSO can help define which packages or components are critical for the application being built, and can create a program on how the organization can work with the community behind that project.

This is why governance, coming from an open source program office, is critical for organizations who wittingly or otherwise use open-source pieces in their code. “Typically, the open source program offices start by the way not on security; they start on tracking open-source licenses. It’s very important especially if you are commercializing software, you need to make sure that you have the proper open-source licenses.” 

And as the offices grow, they have to define and implement some policies, working with the security and engineering teams, as well as providing education on open source and developing champions or experts that can help everyone else do their job. “Everyone is a consumer of open source, but not everyone is a contributor or maintainer of open source,” Perez said, so through training individuals can become contributors, or experts, who can now influence the direction of the software.

The post The need for a chief open source officer appeared first on SD Times.

Our previous stories were devoted to the delayed, noisy and cascaded feedback loops, and today we will shed light on what the weak feedback means.

As you might remember from those previous articles, “Alice” joined a company, working on a digital product to accelerate delivery. The engineering team was relatively small, about 50 engineers, with three cross-functional teams of 6 engineers, shared services for data, infrastructure, and user acceptance testing (UAT). 

Alice knows that code quality and maintainability are important attributes of fast digital delivery. The simple and clean code structure shortens the time to implement a new feature. She knew the ropes thanks to the great books by Robert Martin explaining the concept of clean code. So she asked the engineering teams whether they were addressing findings from Static Code Analysis (SCA) tools that could find code quality issues. Moreover, the engineering teams assured Alice that SCA is an explicit part of the definition of done for every feature.

However, when Alice looked at the SCA report she had a hard time finding a reasonable explanation why there were so many issues. When she observed how engineers followed the definition of done, she found that some of them strictly followed what was prescribed, and some did not. This is what we call weak feedback loops when certain feedback can be skipped or its result ignored. 

The adverse effect of weak feedback are:

• Accumulation of the quality debt 
• Slow down delivery because of unplanned work later

To address such a situation, there were a lot of options. We need to shift left the feedback collection and run it as early as possible and make it a mandatory quality gate. In Alice’s case, it was possible to introduce SCA as a part of pull request verification and impossible to approve the merge if issues were not resolved or enforce such feedback after the merge. The successful mitigation strategy is quality gate enforcement; however, its straightforward introduction with the accumulated debt might lead to the pushback from the business side; it takes time to clean up the accumulated debt and wasted churn. We would recommend incremental enforcement of the quality gate as capabilities improve. 

Another aspect to take into account is when we are introducing a quality gate on the pull request level before the code even merges into a product – the infrastructure cost. The more engineers you have the higher frequency of the pull request you will have the more robust and scalable infrastructure to run all required feedback activities you need to have. Fragile infrastructure will lead to a noise problem; and therefore, push back on the team to make sure you get beyond weak feedback. As a part of a strategy to address weak feedback, make sure that your feedback noise is mitigated and the infrastructure is reliable. 

In the conclusion of these four articles, we would like to reiterate the importance to look at the digital product delivery work organization through the prism of feedback loops, especially: 

• what quality attributes are important
• how fast you can deliver quality feedback 
• how accurate reflective it is, and 
• how you manage impacts and dependencies in case of cascaded feedbacks. 

The post DevOps Feedback Loop Explained: Weak Feedback appeared first on SD Times.

Proprietary software, also known as closed-source or non-free software, includes applications for which the publisher or another person reserves licensing rights to modify, use, or share modifications. Examples include Adobe Flash Player, Adobe Photoshop, macOS, Microsoft Windows, and iTunes. 

In contrast, OSS grants users the ability to use, change, study, and distribute the software and its source code to anyone on the internet. Accordingly, anyone can participate in the development of the software. Examples include MongoDB, LibreOffice, Apache HTTP Server, and the GNU/Linux operating system. 

This means that many organizations are using third-party code and modules for their OSS. While these additions are incredibly useful for many applications, they can also expose organizations to risks. According to Revenera’s 2022 State of the Software Supply Chain Report, 64% of organizations were impacted by software supply chain attacks caused by vulnerabilities in OSS dependencies. 

Although OSS can expose organizations to risks, avoiding OSS software and dependencies is not practical. OSS software and dependencies now play an integral role in development. This is particularly the case for JavaScript, Ruby, and PHP application frameworks, which tend to use multiple OSS components. 

Since software companies cannot realistically avoid using OSS, cybersecurity teams must avoid vulnerabilities associated with OSS by employing software composition analysis (SCA) tools. Additionally, they need to combine SCA with static application security testing (SAST), since proprietary software such as Microsoft Windows and Adobe Acrobat is also used.

Read to learn more about SAST and SCA. This article will also explain how cybersecurity teams can combine SAST and SCA into a comprehensive cybersecurity strategy.

What Is SAST?

SAST is a code scanning program that reviews proprietary code and application sources for cybersecurity weaknesses and bugs. Also known as white box testing, SAST is considered a static approach because it analyzes code without running the app itself. Since it only reads code line by line and doesn’t execute the program, SAST platforms are extremely effective at removing security vulnerabilities at every page of the software product development lifecycle (SDLC), particularly during the first few stages of development. 

Specifically, SAST programs can help teams:

• Find common vulnerabilities, such as buffer overflow, cross-site scripting, and SQL injection
• Verify that development teams have conformed to development standards
• Root out intentional breaches and acts, such as supply chain attacks
• Spot weaknesses before the code goes into production and creates vulnerabilities
• Scan all possible states and paths for proprietary software bugs of which development teams were not aware
• Implement a proactive security approach by reducing issues early in the SDLC

SAST plays an integral role in software development. By giving development teams real-time feedback as they code, SAST can help teams address issues and eliminate problems before they go to the next phase of the SDLC. This prevents bugs and vulnerabilities from accumulating. 

What Is SCA?

SCA is a code analysis tool that inspects source code, package managers, container images, binary files, and lists them in an inventory of known vulnerabilities called a Bill of Materials (BOM). The software then compares the BOM with databases that hold information about common and known vulnerabilities, such as the U.S. National Vulnerability Database (NVD). The comparison enables cybersecurity teams to spot critical legal and security vulnerabilities and fix them.

Some SCA tools can also compare their inventory of known vulnerabilities to discover licenses connected with the open-source code. Cutting edge SCAs may also be able to:

• Analyze overall code quality (i.e., history of contributions and version control)
• Automate the entire process of working with OSS modules, including selection and blocking them from the IT environment as needed
• Provide ongoing alerts and monitoring for vulnerabilities reported after an organization deploys an application
• Detect and map known OSS vulnerabilities that can’t be found through other tools
• Map legal compliance risks associated with OSS dependencies by identifying the licenses in open-source packages
• Monitor new vulnerabilities 

Every software development organization should consider getting SCA for legal and security compliance. Secure, reliable, and efficient, SCA allows teams to track open-source code with just a few clicks of the mouse. Without SCA, teams need to manually track open-source code, a near-impossible feat due to the staggering number of OSS dependencies. 

How To Use SAST and SCA To Mitigate Vulnerabilities

Using SAST and SCA to mitigate vulnerabilities is not as easy as it seems. This is because using SAST and SCA involves much more than just pressing buttons on a screen. Successfully implementing SAST and SCA requires IT and cybersecurity teams to establish and follow a security program across the organization, an endeavor that can be challenging.

Luckily, there are a few ways to do this:

1. Use The DevSecOps Model

Short for development, security, and operations, DevSecOps is an approach to platform design, culture, and automation that makes security a shared responsibility at every phase of the software development cycle. It contrasts with traditional cybersecurity approaches that employ a separate security team and quality assurance (QA) team to add security to software at the end of the development cycle. 

Cybersecurity teams can follow the DevSecOps model when using SAST and SCA to mitigate vulnerabilities by implementing both tools and approaches at every phase of the software development cycle. To start, they should introduce SAST and SCA tools to the DevSecOps pipeline as early in the creation cycle as possible. Specifically, they should introduce the tools during the coding stage, during which time the code for the program is written. This will ensure that:

• Security is not just an afterthought
• The team has an unbiased way to root out bugs and vulnerabilities before they reach critical mass

Although it can be difficult to convince teams to adopt two security tools at once, it is possible to do with a lot of planning and discussion. However, if teams prefer to only use one tool for their DevSecOps model, they could consider the alternatives below.

2. Integrate SAST and SCA Into the CI/CD Pipeline

Another way to use SAST and SCA together is to integrate them into CI/CD pipeline.

Short for continuous integration, CI refers to a software development approach where developers combine code changes in a centralized hub multiple times per day. CD, which stands for continuous delivery, then automates the software release process.

Essentially, a CI/CD pipeline is one that creates code, runs tests (CI), and securely deploys a new version of the application (CD). It is a series of steps that developers need to perform to create a new version of an application. Without a CI/CD pipeline, computer engineers would have to do everything manually, resulting in less productivity.

The CI/CD pipeline consists of the following stages:

1. Source. Developers start running the pipeline, by changing the code in the source code repository, using other pipelines, and automatically-scheduled workflows.
2. Build. The development team builds a runnable instance of the application for end-users.  
3. Test. Cybersecurity and development teams run automated tests to validate the code’s accuracy and catch bugs. This is where organizations should integrate SAST and SCA scanning.
4. Deploy. Once the code has been checked for accuracy, the team is ready to deploy it. They can deploy the app in multiple environments, including a staging environment for the product team and a production environment for end-users.

3. Create a Consolidated Workflow with SAST and SCA.

Finally, teams can use SAST and SCA together by creating a consolidated workflow.

They can do this by purchasing cutting-edge cybersecurity tools that allow teams to conduct SAST and SCA scanning at the same time and with the same tool. This will help developers and the IT and cybersecurity teams save a lot of time and energy.

Experience the Kiuwan Difference

With so many SAST and SCA tools on the market, it can be challenging for organizations to pick the right tools for their IT environments. This is particularly true if they have limited experience with SAST and SCA tools.

This is where Kiuwan comes in. A global organization that designs tools to help teams spot vulnerabilities, Kiuwan offers Code Security (SAST) as well as Insights Open Source (SCA).

Kiuwan Code Security (SAST) can empower teams to:

• Scan IT environments and share results in the cloud
• Spot and remediate vulnerabilities in a collaborative environment
• Produce tailored reports using industry-standard security ratings so teams can understand risks better
• Create automatic action plans to manage tech debt and weaknesses
• Give teams the ability to choose from a set of coding rules to customize the importance of various vulnerabilities for their IT environment

Kiuwan Insights Open Source (SCA) can help companies:

• Manage and scan open source components 
• Automate code management so teams can feel confident about using OSS
• Integrate seamlessly into their current SDLC and toolkit

Interested in learning more about how Kiuwan’s products? Get demos of Kiuwan’s security solutions today. Developers will see how easy it is to initiate a scan, navigate our seamless user interface, create a remediation action plan, and manage internal and third-party code risks.

Content provided by Kiuwan. 

The post Combining Static Application Security Testing (SAST) and Software Composition Analysis (SCA) Tools appeared first on SD Times.

New features and capabilities include the ability to perform code analysis for Kotlin apps for mobile development, which is an early-stage beta release, and Intelligent SCA for Python and Golang, which is also a beta release, that allows developers to identify attackable open source vulnerabilities in their code.

The release also includes workflow enhancements like improved build rules that allow for  automatic detection and interception of attacker reachable open-source vulnerabilities, interactive remediation that enables developers to specify custom validation for the tool to recognize in scan results, enhanced vulnerability descriptions, branch selection, and richer data flow visualizations. 

“Customers are already using ShiftLeft CORE to make security fixes earlier in the development cycle where they are less painful for devs and result in significantly less security debt for the application. That said, the increased frequency of scans and greater volume of vulnerability information can create information overload,” said Alok Shukla, the VP of products at ShiftLeft. “The ‘Velocity Update’ to ShiftLeft CORE helps them easily browse and triage high volumes of attackable dataflows and intelligently automate build decisions based on attackability exposure in each pull request.”

The post ShiftLeft CORE gets new vulnerability identification features appeared first on SD Times.

Things like static code analysis (SCA) tools offer a way to verify quality, security, and compliance without adding too much extra time to the process. According to a webinar from Perforce, just because a developer has access to a tool, however, doesn’t mean they are using it 100% effectively. 

In the webinar, Rod Cope, chief technology officer at Perforce Software, shared five things development teams can be doing to increase their development output using these tools:

Use SCA to check security of code 

According to Cope, a lot of organizations lack the time, focus, and proper tools to prevent attacks. Further, most attacks are related to trust issues, such as cross-site scripting, SQL injection, or unvalidated inputs. 

“Static code analysis can help by not requiring any additional time. You just run the tool,” said Cope.

Use SCA to enforce industry and coding standards

SCA tools can be used to enforce key standards, such as DISA STIG, CWE, MISRA, CERT, SAMATE, OWASP, DO-1788, FDA validation, and more. 

Cope recommends that even companies that are not in an industry that requires compliance with one of these standards still should pick one and follow it. “We found it’s a best practice to adopt one of these standards so at least you’re following something and you know these standards are good, reliable, proven in the industry,” he said. 

Integrate SCA and CI into your development process

This helps cut down on testing time because as developers write code it gets scanned and verified in the context of the rest of the code. As a result, any security or compliance issues get caught immediately, rather than closer to the end of the process, which would require developers to have to go back in and rework the code.  

According to Cope, development teams using daily builds experience a 90% increase in output and a 36% reduction in defect rate when testing at each check-in point. 

In order to work successfully in a CI environment, SCA tools need to be automated, scalable, efficient by only analyzing the affected code, and able to report only the relevant information for a given context, Cope explained. 

Use SCA to validate legacy and open-source software

Cope added that all open-source components that are in use should be scanned by the SCA tool as well.

He also recommended that companies who make use of contractors to write code ask those contractors to run SCA on that code and report the results. 

“The more you scan upfront the cheaper it is and faster it is to fix those defects and to avoid issues,” said Cope. 

Use SCA to help developers improve code quality

SCA isn’t just a scanner for finding bugs; it can also be used as an educational tool. Developers can learn from the results to improve the way they write code by learning about common programming errors, security vulnerabilities, and standards. 

“As they create errors and the tool tells them what they did wrong, a good tool also tells them how to do it right, how to fix it, what is the underlying issue, how to avoid those issues in the future, how to write better clean code with fewer vulnerabilities,” said Cope.    

For more information watch the webinar “5 Ways to Improve Developer Output.”

The post 5 ways developers can use SCA to increase code output appeared first on SD Times.

In the past 12 months, 929 next-generation software supply chain attacks were recorded. By comparison, 216 such attacks were recorded between February 2015 and June 2019.

“Following the notorious Equifax breach of 2017, enterprises significantly ramped investments to prevent similar attacks on open-source software supply chains,” said Wayne Jackson, the CEO at Sonatype. “Our research shows that commercial engineering teams are getting faster in their ability to respond to new zero-day vulnerabilities. Therefore, it should come as no surprise that next-generation supply chain attacks have increased 430% as adversaries are shifting their activities ‘upstream’ where they can infect a single open-source component that has the potential to be distributed ‘downstream” where it can be strategically and covertly exploited.”

Next-generation software supply chain attacks involve the intentional targeting and compromising of “upstream” open-source projects so that attackers can then exploit vulnerabilities when they inevitably flow “downstream,” according to Sonatype.

In 2019 Darmstadt University researchers found that 391 highly influential project contributors affect more than 10,000 components through their complex web of dependencies. If an adversary were to gain access to one of these maintainers, this could dramatically widen the impact of their attack.

These types of attacks include Octopus Scanner, which affected 26 open-source projects on GitHub and targeted the tools developers were using to build their code; and electron-native-notify, which focused on getting a malicious package into a build chain. 

Currently, the most common type of attack is Typosquatting, an indirect attack vector that preys on developers making otherwise innocent typos when searching for popular components. If developers accidentally type in a wrong name, they might accidentally install a malicious component of a similar name. 

Another common attack is Malicious Code Injection, which is carried out through a variety of means, including stealing credentials from a project maintainer. 

According to the report, these next-gen attacks are possible for three main reasons.

One is that open-source projects rely on contributions from thousands of volunteer developers, making it difficult to discriminate between community members with good or bad intentions. 

Secondly, the projects incorporate up to thousands of dependencies that may contain known vulnerabilities. Lastly, the ethos of open source is built on “shared trust,” which can create a fertile environment for preying on other users, according to the report. 

On the other hand, legacy software supply chain attacks involve waiting for new zero-day vulnerabilities to be publicly exposed and then taking advantage of them before they can be fixed. The study found that 51% of organizations require more than a week to remediate new zero-day vulnerabilities.

The report found that to fix these issues, teams that are investing more in software composition analysis (SCA) open-source automation capabilities are able to handle the issues faster.

High performing development teams are 26 times faster at detecting and remediating open-source vulnerabilities, and deploy changes to code 15 times more frequently than their peers.

They are also 59% more likely to use automated software composition analysis (SCA) and are almost 5 times more likely to successfully update dependencies and to fix vulnerabilities without breakage. 

“It was really exciting to find so much evidence that this much-discussed tradeoff between security and productivity is really a false dichotomy. With the right culture, workflow, and tools development teams can achieve great security and compliance outcomes together with class-leading productivity,” said Dr. Stephen Magill, the principal scientist at Galois and the CEO of MuseDev.

The post Report: A 430% increase in next-generation supply chain attacks in last year appeared first on SD Times.

Look, every time a new technology, process, or technique comes along there are some people that think that it’s the answer to everything. It’ll solve software security, save development and testing time, and maybe even eliminate world hunger while it’s at it. Ok, I made that last one up. But saying that SCA is eventually going to replace SAST is essentially saying that because you’re looking for known vulnerabilities in other people’s code, you no longer have to check your own. 

RELATED CONTENT: 
4 best practices to build more perfect software, faster
Report: Organizations fail to remediate app security vulnerabilities

SCA is Software Composition Analysis, and is certainly a valuable part of your toolkit for securing your software systems. Theoretically it works hand-in-hand with a software bill-of-materials (something that currently mostly doesn’t exist) and keeps track of the other libraries and components that are used in your application. 

These tools mostly just scan the open-source components for your application and don’t necessarily work with a bill-of-materials. (NOTE: some of these tools also perform other functions, like look for cut-paste snippets from OSS projects, or identify and manage OSS license issues. Both are interesting and important, but still not a replacement for what SAST is doing.) 

One main function of SCA is to check components in your application for known vulnerabilities. This is important so you can avoid zero-day issues, as well as to address the problem that you might not have source for some components and therefore you’re unable to utilize SAST for them.

The popular and useful security organization known as the Open Web Application Security Project (OWASP) has even added this concept to the latest iteration of the popular OWASP Top 10 list of the most critical security risks today. It appears as item A9 – Using Components with Known Vulnerabilities. If you’re not using OWASP, you probably should. If you’re not checking your application for known vulnerabilities against the CVE and NVD databases, you should. Such sources keep track of real attacks happening and what patches and other remediations are available. OWASP has been built a tool called OWASP Dependency Check that can do this work for you. Like all that OWASP has to offer, it comes without cost.

 Supply chain assurance
I must admit that not too many years back, software supply chain was a mostly overlooked topic. Some key individuals, many of them part of the Software Supply Chain Assurance Forum (SSCA), worked hard to highlight this weakness in application security by focusing not just on your code, but on your supply chain. In fact, SSCA forum, which is hosted by the U.S. Department of Defense (DoD), Department of Homeland Security (DHS), General Services Administration (GSA), and the National Institute of Standards and Technology (NIST), was formerly called the Software Assurance Forum (SwA) and they changed the name to help put more focus on the supply chain. But the intent was to expand the focus, not move it from your code to someone else’s.

In practice, SCA is a testing activity – making sure that your application is checked against a list and is in conformance with that list (such as known vulnerabilities like NVD). Conversely, SAST is primarily NOT a testing function (heresy, I know…) but rather an engineering function. The smallest value of SAST is to find a weakness or vulnerability earlier than pen-testing would. The greatest value of SAST is to guide you to harden your code in the first place. 

Stop trying to plug leaks and build code that won’t leak in the first place. It’s the only way to get ahead of the curve in application security. If you do it perfectly, you’ll still need SCA, because you still have the problem of all those components in your application, as well as other programs it interacts with and the OS itself. If you do SCA well, you still need SAST because while you’ve fixed problems in other people’s code, you’ve done nothing for your own. The purposes complement each other, not replace each other.

In summary, SCA is great, you want it, in fact you need it. I’m happy that it’s getting more attention than it has in the past. But saying it will replace DAST or SAST is like saying you have a hammer and don’t need a screwdriver.

The post When does SCA replace SAST or DAST? appeared first on SD Times.

• By 2022, software composition analysis (SCA) will surpass traditional AST tools (SAST, DAST) as the primary tool in the AppSec toolbelt. 
• By 2023, limited security testing capabilities incorporated into the development toolchain will identify more vulnerabilities than dedicated SAST solutions.
• By 2022, 10 percent of coding vulnerabilities identified by static application security testing (SAST) will be remediated automatically with code suggestions applied from automated solutions, up from less than 1 percent today.

RELATED CONTENT: Shifting left for better security? It’s just as important to shift right too

If you’re a provider of software composition analysis solutions, then the first bullet point obviously excites you, but by the same token it also challenges long-held security paradigms. For those of you unfamiliar with SCA, it’s the ability to identify latent vulnerabilities in applications that originate not from the code teams create, but from the code they depend upon. Such dependencies are very common in modern applications due to the proliferation of high-quality open-source components that address common tasks within a given programming language or platform. Since open-source libraries are the foundation for modern application development, it makes sense that tackling any latent unpatched vulnerabilities in them should be a primary task. In other words, if you address any issues in your libraries, you’re free to focus on issues in your custom code. SCA solves the former problem, while traditional tools like SAST solve the latter.

The second bullet is more nuanced. Essentially, it states that traditional SAST solutions will take a back seat to limited testing capabilities baked into IDEs or other areas of the toolchain. While traditional SAST has a reputation for long test times, this is more a function of the depth of analysis in the checkers than the value of the testing. By moving elements of code analysis into IDEs or into functional testing, this allows traditional SAST to focus on the hard task of discovering bugs within the entire application and have the IDE-based solution look for incremental issues. By incrementally checking code within the IDE, fewer defects are logged, which both increases the quality of code being committed while reducing testing costs. The reduction in testing costs for standard security issues then frees QA teams to focus their attention on architectural or system-level issues rather than preventable security issues.

The last bullet is more interesting. Automatic remediation of defects implies that security tools could become code generators. While it’s fairly straightforward to determine whether basic security defects exist within the code, there’s a fairly wide gap between detection and semantically appropriate resolution. Put another way, would you rather trust your engineers to develop a security fix in your business logic, or have a tool provide a standardized fix with generic assumptions? 

While I’m not yet comfortable with automated resolution of security issues, I am a huge fan of contextual training. When developers are armed with easy-to-use tools that identify security defects in their IDE and explain precisely why the code fails to meet security targets, we not only are able to address the defect but simultaneously help prevent future occurrences. In the end, security tooling should focus on enabling developers to create more secure code prior to it ever being available to customers.

At a high level, the three predictions from Gartner boil down to providing development teams with the security tools they need, when they need them, without becoming roadblocks to development. When security tools become an impediment to development, engineers under tight deadlines will find ways to bypass them. This is why context-sensitive security information, both detection and remediation guidance, belongs in an IDE. It’s also why having transparent security testing operating in parallel to existing functional testing is a hot topic, and why continuous monitoring for new security disclosures within dependencies is crucial for released code. Each provides contextually valuable security information enabling the delivery of higher quality code – and who wouldn’t want that!

The post The future of application security appeared first on SD Times.