WIXLIB

PA R T O N E : S TAT E O F A P P L I C AT I O N S E C U R I T Y T O D AYIntegrated application security testing(IAST)IAST finds security vulnerabilities by installing an agent which runsalongside the target application. IAST is commonly used duringcontinuous integration (CI) and quality assurance (QA) phases.There are two variants of IAST:Passive IAST is used for applications running in testingenvironments. When the application goes through use case-basedQA tests, the agent identifies potential security vulnerabilities. Thisapproach finds a subset of vulnerabilities that can also be foundusing SAST or DAST.Active IAST is used for applications running in live environmentsand acts as an enhancement for DAST tools. The agent is installedon the running application and performs DAST tests against theapplication. The agent can view stack trace information and can dodetailed behavior analysis on the server side, so the DAST processand results can be improved. Active IAST helps reduce the scanningtime and validate attack results for DAST.Runtime application security protection(RASP)RASP involves installing an active agent on a running applicationand using this agent to protect the application at runtime. Incontrast to other AST tools, RASP tools are used against activevulnerability exploits on applications running in productionenvironments. RASP agents can detect and prevent predefinedT H E C O M P L E T E G U I D E T O D E V ELO P ER- F I R S T A P P L I C AT I O N S EC U R I T Y13

PA R T O N E : S TAT E O F A P P L I C AT I O N S E C U R I T Y T O D AYsets of vulnerabilities, but these agents may degrade applicationperformance, especially under heavy usage, DoS, or DDoS attacks.FuzzingFuzzing (or fuzz testing) uses automated or manual methods toprovide invalid, unexpected, or random data as inputs to runningapplications in a test environment. As these inputs are sent, thetarget application is continuously monitored for exceptions whichmay include crashes, abnormal behavior, or potential memoryleaks. Fuzzing can provide additional information about a targetapplication and serves as a complementary method for DAST.Software composition analysis(SCA)SCA analyzes an application to determine its third-partycomponents, frequently focused on open source software (OSS)security issues and license compliance. SCA is often used in earlyphases of software development.Today’s SCA tools create an inventory of third-party componentsand check these components for known vulnerabilities or otheroperational risks such as license compliance. In some cases,they also offer a library of verified and compliant components fordevelopers to use.Penetration testingPenetration testing involves automated and manual tests that aimto test the security controls of running applications. In most casesT H E C O M P L E T E G U I D E T O D E V ELO P ER- F I R S T A P P L I C AT I O N S EC U R I T Y14

PA R T O N E : S TAT E O F A P P L I C AT I O N S E C U R I T Y T O D AYpenetration tests only cover applications running in production, butthey can also be scoped to cover pre-production environments.Penetration tests can be conducted by internal or external teams,and are typically summarized in reports. The results of thesetests are already validated by the testing team, but penetrationtests require planning and take longer than automated scanningmethods. In addition to technical vulnerabilities, penetration testscan discover faults in the logical flow or user experience of theapplications in scope.Bug bountiesBug bounties are crowd-sourced security testing programs whichleverage individual security researchers who get paid based onthe vulnerabilities that they discover. Bug bounties serve as acomplementary solution to all of the methods noted above, butdon’t typically provide comprehensive coverage for the securityposture of applications.For the average organization today, application security consists ofa small set of testing tools integrated with the software developmentcycle. Depending on your organization’s maturity level, tools, andcapabilities, application security may either be treated as the finalgate before deploying an application, or alternatively as a series ofintegrated tests as part of the development cycle.Let’s take a look at these two approaches and what they mean foryour developers.T H E C O M P L E T E G U I D E T O D E V ELO P ER- F I R S T A P P L I C AT I O N S EC U R I T Y15

Part two:Traditional vs.end-to-endsecurityT H E C O M P L E T E G U I D E T O D E V ELO P ER- F I R S T A P P L I C AT I O N S EC U R I T Y16

PA R T T W O : T R A D I T I O N A L V S . E N D -T O - E N D S E C U R I T YThe traditional approachHaving security as a gate prior to deployment is a commonapproach, and often the first step for organizations just startingwith application security. This “traditional” approach consists ofa single security test or a series of security tests that take placeduring the quality assurance phase. These security tests are run bysecurity teams or third parties, and the outcomes of the securityresults are delivered in bulk to developers for remediation. The tests’findings are then expected to be fixed before the application goesinto production.Application security as a gatePRCode reviewCommitCI / STSCADASTIASTCode / TestCDShipSASTDASTSCAIASTQA &IntegrationtestingT H E C O M P L E T E G U I D E T O D E V ELO P ER- F I R S T A P P L I C AT I O N S EC U R I T Y17

PA R T T W O : T R A D I T I O N A L V S . E N D -T O - E N D S E C U R I T YIn this traditional gate approach, teams most commonly use SAST,DAST, IAST, and SCA tools.Although having security as a gate is better than having noapplication security at all, it causes developer friction and delaysdelivering secure applications. This is due to three main reasons:1. L ate security feedback causes confusion. Security feedbackthat comes at a later stage in development (often weeks afterthe code’s creation) means that developers have already movedon to the following sprint or the next project, so the vulnerablecode in question is no longer top of mind. It can take a while fordevelopers to refamiliarize with the code and context, and thefixes often require additional sprint planning, potentially delayingcurrent projects. “More than 70 percent of all flaws remainone month after discovery and nearly 55 percent remain threemonths after discovery” per the State of Software Security ReportVolume 10 by Veracode.32. S can results have a high noise-to-signal ratio. Traditionalapplication security tools generate multiple false positives forevery true positive, so reviewing scan results is a challengingtask. These reviews are generally done by security teams whohave limited knowledge about the scanned projects, whichmakes auditing scan results difficult and labor-intensive. Anotherapproach is to push raw scan results to developers withoutreviews, but this puts the burden of evaluation onto developers,deprioritizing their effort to actually fix the issue.In both cases, a considerable amount of false positives maketheir way to developers as items to be fixed, causing confusionand frustration.-------3: State of Software Security Report Volume 10, VeracodeT H E C O M P L E T E G U I D E T O D E V ELO P ER- F I R S T A P P L I C AT I O N S EC U R I T Y18

PA R T T W O : T R A D I T I O N A L V S . E N D -T O - E N D S E C U R I T Y3. M anual reviews cause bottlenecks. When scan results aregenerated by automated tools, they still require manual reviewto identify true positives and eliminate false positives. Securityteams are greatly outnumbered by developers and they simplycan’t keep up with the sheer volume of raw scan results that needtheir attention. Manual reviews can take days and even weeks forthe average project, creating a bottleneck and delays in projecttimelines. Delays can be even more frustrating in cases wheremanual review results don’t meet expectations. In most cases,delayed security results mean teams have to ship releases withknown vulnerabilities, with no time to fix these issues to meetproject timelines.Another downside of traditional security is that if a project isn’ta priority, it won’t get manual reviews. “Raw” scan results mayalso be shared directly with developers, which are non-validatedscan results with a high false positive (non-finding) ratio. Sincethese results can quickly become frustrating and developerscan become desensitized to so many false positives, raw scansare either turned off or their results get ignored. Either optionadds more risk to your organization. If security issues aren’taddressed in time, they can become a legal liability—like if asecurity issue is found to be a source of a data breach, or if notremediating a known issue is a breach of one (or more) of yourcustomer contracts.The end-to-end approachOrganizations that are more mature in application securityemploy an end-to-end approach, which starts in earlier stages ofdevelopment and has more points of interaction throughout thedevelopment lifecycle.T H E C O M P L E T E G U I D E T O D E V ELO P ER- F I R S T A P P L I C AT I O N S EC U R I T Y19

PA R T T W O : T R A D I T I O N A L V S . E N D -T O - E N D S E C U R I T YEnd-to-end approachPRIDE nfigurationShipSASTSCACode reviewCI / TestingSASTSCADASTIASTCDDASTCode / TestSAST PenetrationDAST testingSCA Bug bountyQA &IntegrationtestingThe end-to-end approach provides earlier security feedback todevelopers and leverages integration and automation capabilities ofsecurity tools. But like traditional security, end-to-end security stillhas several friction points:1. I ntegrations require a lot of upkeep and frequently breakbecause of version updates. Although security tools areintegrated with the development process, these integrationsbreak often. Developers have to drop their current tasks toaddress a security issue and log into another portal to deal witha different tool or system. Security feedback lacks context andcontext-switching remains a challenge. The user experiencebecomes problematic and inefficient for developers.2. S ecurity teams and development teams continue towork in silos. Changing your tooling isn’t enough to changeT H E C O M P L E T E G U I D E T O D E V ELO P ER- F I R S T A P P L I C AT I O N S EC U R I T Y20

PA R T T W O : T R A D I T I O N A L V S . E N D -T O - E N D S E C U R I T Yyour processes. Silos between the security and applicationdevelopment teams still have to be addressed for end-toend security to work. Integrating tools streamlines part of theapplication security process, but this approach again fallsshort of nurturing more collaboration between security anddevelopment teams.Security teams also still act as reviewers for testing results. Forexample, every commit on the main branch gets scanned andnew alerts are sent to the security team for review. The securityteam still has to triage and send issues back to developers tofix, and the team likely still has a gating process on release. Thisis a better approach than having security tests as a gate sincesome things get caught early, but these teams still lack commonprocesses and platforms to collaborate. With silos and poorcommunication, issues are pushed back and forth betweenteams, often leading to delays and sometimes conflict.3. A utomating traditional tools doesn’t solve the false positiveproblem. It’s exciting to think about automated applicationsecurity tools. But in reality, automating scans and pushingresults to an issue tracker leads to a flood of non-actionableissues. Here the problem is false positives and developersbecoming desensitized to noise. With too many alerts, developersignore test results (and mark them all as “false positives” or“won’t fix”). Traditional security tools lack the customizability toadjust sensitivity or improve results over time, so when results arepushed into developer flows, developers switch these tools off.4. T raditional tools fail to keep pace with the software ecosystem.Today’s software ecosystem consists of open source, newprogramming languages, new frameworks, and emerging toolsthat evolve at a breakneck pace. Since traditional commercialtools are created, updated, and supported by small vendor teams,T H E C O M P L E T E G U I D E T O D E V ELO P ER- F I R S T A P P L I C AT I O N S EC U R I T Y21

PA R T T W O : T R A D I T I O N A L V S . E N D -T O - E N D S E C U R I T Ythey struggle to keep up. There’s also very limited communicationbetween these vendors and the developer community, requiringresearch teams to proactively look for OSS vulnerabilities—anunscalable task with 100 million-plus public repositories. Asa result, most commercial tools do well in a few aspects ofapplication security or limit their support to a small part of thesoftware ecosystem. This means your developers and securityteams either have to work with multiple tools and vendors for asingle use case, or invest in home-grown solutions to fill the gapsthat your commercial tools create.DevSecOps and shifting leftRelatively newer approaches to application security—includingDevSecOps and shifting security left—have suggested significantimprovements to both traditional and end-to-end security. However,they’ve driven little change since the tools and processes remainmostly the same.Even with DevSecOps, traditional and end-to-end securityapproaches still share common problems:1. High friction between developers and security teams,2. A pplications frequently shipped with known vulnerabilities (83percent of applications have one security flaw on initial scan andtwo out of three applications fail to pass tests based on OWASPTop 10 and SANS 253),3. Low fix rates for discovered vulnerabilities (only 56 percent of-------3: State of Software Security Report Volume 10, VeracodeT H E C O M P L E T E G U I D E T O D E V ELO P ER- F I R S T A P P L I C AT I O N S EC U R I T Y22

PA R T T W O : T R A D I T I O N A L V S . E N D -T O - E N D S E C U R I T Ysecurity flaws are fixed, with 24 percent of high-severity flaws leftunfixed by developers3), and4. L ong exposure periods for detected issues (the median time tofix security flaws is 59 days3).With all of these challenges combined, it’s little surprise that webapplications have been reported as the main cause of securitybreaches over the last five years.4-------3: State of Software Security Report Volume 10, Veracode4: 2016, 2017, 2018, 2019 and 2020 Data Breach Investigation Reports, VerizonT H E C O M P L E T E G U I D E T O D E V ELO P ER- F I R S T A P P L I C AT I O N S EC U R I T Y23

Part three:Developer-firstapplication securityT H E C O M P L E T E G U I D E T O D E V ELO P ER- F I R S T A P P L I C AT I O N S EC U R I T Y24

PART THREE:D E V ELO P ER- F I R S T A P P L I C AT I O N S EC U R I T Y W I T H G I T H U BDeveloper-first, community-powered securitywith GitHubUnless security issues can be identified and fixed by yourdevelopers early in the development lifecycle, technical debt willcontinue to be a challenge for your software ecosystem. And likemany other challenges, application security problems are easiestand most cost-effective to solve at the source. To actually drivedown the number of vulnerabilities in production code, we need topartner with developers in their preferred environment and use theirexisting workflows.There’s only one way to shift security left and succeed againstoverwhelming technical debt: Putting developers front andcenter for application security.By prioritizing developers and giving them the tools to work inthe most efficient way, GitHub takes responsibility for makingthe software we all rely on more secure. GitHub creates secureapplications with a community-powered approach that addressesfeedback early and often from developers; empowers researchersto enhance and embellish search capabilities; and crowd-sourcesbug bounty testing programs. Instead of relying on multiple toolsthat cause friction in the process, GitHub offers a unified, native,and automated solution within the developer workflow. You canaddress security risks earlier, automate vulnerability fixes, and havebetter security governance to build and protect applications.T H E C O M P L E T E G U I D E T O D E V ELO P ER- F I R S T A P P L I C AT I O N S EC U R I T Y25

PART THREE:D E V ELO P ER- F I R S T A P P L I C AT I O N S EC U R I T Y W I T H G I T H U BHow to improve your project’s securitywith GitHub1. Start with security in mindReviewing security requirements and identifying potential risks withyour project prior to implementation are critical steps for preventingexpensive vulnerability fixes. Here are a few ways to put theminto practice:Apply security best practices for project configurationConfiguring your project to match security best practices canprevent a lot of problems. Reviewing accounts and access settings(including roles and responsibilities, two-factor authentication, gitover SSH, managing teams, integrations, and projects) along withsetting a SECURITY.md vulnerability disclosure and reporting policycan go a long way.Model threats for the projectSoftware threat modeling is the set of activities that helps identifythe potential threats, threat actors, and vulnerable components ina project. Threat modeling requires analyzing the business logicand flow of sensitive data through library APIs like source and sink.Source is the part of code where data is ingested, and sink is thepart of code where data flow is completed.CodeQL is the industry-leading semantic code analysis enginethat lets you query code as though it were data—making it easy todiscover a bad pattern and then find similar occurrences acrossyour entire codebase. Behind the scenes, CodeQL adaptive threatT H E C O M P L E T E G U I D E T O D E V ELO P ER- F I R S T A P P L I C AT I O N S EC U R I T Y26

PART THREE:D E V ELO P ER- F I R S T A P P L I C AT I O N S EC U R I T Y W I T H G I T H U Bmodeling semi-automatically boosts your JavaScript securityqueries with machine learning to find more security vulnerabilitiesand improve taint specifications. Taint specifications capture therole of library APIs—source and sink—and are a critical componentof any taint analyzer that aims to detect security violations basedon information flow. A boosted query then produces a ranked list ofadditional results for you to review. With adaptive threat modeling,your JavaScript and TypeScript queries will identify more securityproblems. For example, using this technique GitHub Security Labwas able to find 118 new NoSQL injection

attack vector for breaches, in retrospect, many of the biggest recent breaches are known to have leveraged vulnerabilities at . security updates, secret scanning, and more. You can address security risks earlier to automate vulnerability fixes and ship more secure applications, faster.