Traditional Software Development Life Cycle Models | An Introduction

Developing software in today's IT corporate landscape is a complex process that can be broken down into several phases. These phases can be defined by different methodologies & models utilized by software engineers. The steps of the development process are defined as the Software Development Life Cycle (SDLC). This lifecycle of application development is usually comprised of four to six phases, namely:

• Planning & Requirements • Architecture and Design • Test Planning • Coding • Testing & Results • Release & Maintenance

Security Training - Core security training as well as specialized and ongoing training for all project team members happens throughout the project.

There are several traditional software development models that engineers utilize for developing software including, Waterfall, Agile, Scrum, and DevOps. Each of these models have various benefits and challenges.

• The Waterfall model is a linear, step-by-step, sequential development strategy with a top-down approach and specific goals for each phase, allowing for easier management and departmentalization.
• Agile is a more collaborative model that has teams build modules in increments after a basic initial design is determined. It’s then followed by evaluations and more module development. Scrum is included in the Agile model.
• DevOps seeks to create collaboration among IT silos so that QA teams, software developers and operations admins/engineers work together throughout the SDLC.

Traditional SDLC models do not include security testing or secure coding into their methodologies or phases. Because of this, security is often an afterthought during the build process. The disconnect between management and the actual developers can be vast when it comes to application security.

Security flaws that are found late in the SDLC are allowed to stay, since quickly-developed, functional applications are often top priority for the sake of revenue and sales. The alternative is a security quick fix, which often results in the accumulation of technical debt being added at the end of the development process to partly mitigate security flaws. The result is an insecure product being deployed and sent to end-users.

DevOps seeks to create collaboration among IT silos so that QA teams, software developers and operations admins/engineers work together throughout the SDLC. It is important to note that traditional SDLC models do not include security testing or secure coding into their methodologies or phases. Deploying software without consistently checking for security flaws at every phase in the SDLC is like sending a new car out to a car dealer for sale without having run any safety checks on it.

Security Training Phase

As software engineering is a discipline that is always evolving, teaching security engineering concepts is a valuable next step for talented team members that have a drive to learn and a passion to produce applications that perform well and are also secure. Interestingly, approximately 80 percent of cyber-attacks carried out on major corporations can be easily avoided, since many of such attacks are carried out by so-called script kiddies who use automated tools without much knowledge of actual hacking.

Generally, they simply probe different IT systems and attempt to scan for vulnerabilities to invade any system that they can access. Thus, basic security training for your employees can help to mitigate 80 percent of potential cyber-attacks on your company. Security training can be broken up into three phases,

Security Aware

Becoming security-aware is a necessary prerequisite for adopting correct, security best practices during SDLC phases. It is thus necessary for all project team members to complete basic security training modules, which should always include network security, cryptography, and application security.

In addition to this, more specific topics such as social engineering, phishing, secure coding, and basic hacking methodologies should be taught, along with different secure SDLC models. A comprehensive teaching of the OWASP Top 10 is also mandatory, and obtaining the Security+ certification is also helpful.

Security Skilled

After establishing basic security knowledge, your development personnel can take more advanced security training (e.g. secure coding, CISSP certification) and engage in hands-on exercises, such as Capture the Flag (CTF), Attack-Defense, or gamified security challenges such as Jeopardy style security trivia games.

Security Champion

The last level in security training encompasses learning advanced secure coding methodologies in relation to corporate platforms and frameworks. A very important step that will help to assess the security training of employee, is giving them the responsibility of conducting security scans, security audits, and code reviews for other software engineers.

Some advanced-level responsibilities can also include teaching other engineers security best practices - via blogs, internal corporate wiki posts, group discussions, etc. - and organizing the security competitions or gamified cyber-challenges for the security aware and security skilled developers.

Training in Secure Software Development Also Breaks Down to Understanding the OWASP Top 10

The OWASP Top 10 is a list of the ten most critical web security risks that every web application software engineer should be aware of, while the CWE 25 Errors offers insights into the 25 most critical software development security errors that are commonly found in applications. The OWASP Top 10 includes processes for integrating SSDLC strategies into classical SDLC models, and encompasses some noteworthy security issues:

• Injection (e.g. SQLi) • Cross-Site request forgery (CSRF) • Cross-Site Scripting (XSS) • Lack of efficient Transport

The OWASP Application Security Verification Standard (ASVS) is also important for engineers to be acquainted with, as the ASVS aids in secure application development and testing. Educating personnel on such cybersecurity training materials also assists with achieving regulatory, legal compliance, i.e. PCI DSS (which necessitates annual training in secure application development and makes addressing the OWASP Top 10 risks mandatory), Sarbanes-Oxley, Graham Leach Bliley, and other regulations.

Requirements Phase

The focus of a traditional Software Development Life Cycle (SDLC) is on quickly developing feature-rich, efficient, and productive applications. Where does security fit into this picture?

The pressure to quickly produce quality products often-times overshadows implementing detailed security practices into the lifecycles.

We help teams identify where and how vulnerabilities have the potential of impacting your applications and software. In addition, we assist teams in adding the secure portion to the SDLC for future projects and applications.

Traditional SDLC models such as Agile, Waterfall, etc. include several phases for development teams to operate in order to deliver a finished software product.

The Requirements Phase Within a Secure SDLC Expands on Traditional Requirements Phases

The Requirements Phase - this is the phase where teams conduct extensive planning in order to set the blueprints and foundation for the software that software engineers will implement. Traditionally, this step would involve a meeting amongst every key member of a development team, along with certain executives such as the CFO to determine the financial budget for the software. The CTO would determine what features need to be implemented in the application. Stakeholders can also voice their opinions during this phase.

In the past, traditional SDLC, security was generally not contemplated or discussed. The specific goals, needs, features, end-user experience, timeframe, and finances associated with the project usually take precedence.

It is also important to note that this phase - called iteration 0 in Agile - differs depending on the SDLC model that is utilized. While this phase may be more comprehensive in the Waterfall model due it's nature of presenting unchanging goals, Agile development, which focuses more on modular, flexible steps and goals that are known to potentially change, has a much shorter requirements phase.

The requirements phase traditionally focuses on the end-user experience. Common discussions during this phase include: architectural decisions, application appearance options, what data will be stored and transmitted, and interactions that may exist within the system between the user and the application. Lastly, the features that make the application or software marketable are discussed.

The requirements phase includes utilizing complex analysis of what the customer needs and how the software will meet those needs. In addition to this, the requirements phase - like most phases of SDLC models - focuses on releasing products that are feature-rich and perform well as quickly as possible. Getting the product to market quickly, return on investment (ROI), innovative features, and increasing revenue become a primary impetus for software development.

Traditional SDLC Requirements Phase Focuses on the Customer, Not Always Security

During this phase of the SSDLC, security engineers assist in determining the scope of the software that needs to be hardened. They determine the probability of attack surfaces in the application and what critical sections, at a minimum, will require threat modeling. In establishing the areas of the application that are most likely to be targeted by attackers, security experts can project and prevent likely attack vectors and potential exploits.

The Secure Software Development Life Cycle (SSDLC) differs from traditional non-secure SDLC's in several ways across all development phases. Secure SDLC's include the assignment of security engineers to development teams in order to oversee the development process, conduct code reviews and security testing, and to guide the use of secure coding in software projects.

Security in the requirements phase is cost-effective.

Development teams can write evil use cases and security stories during requirements and threat modeling.

In an SSDLC, evil user stories can help developers take on the persona of attackers, which - combined with the white-hat persona (defensive cyber-specialist) - can assist with developing a secure application by shifting to an attacker's mindset.

Maintain a Risk Profile for the Application

Security engineers aid the development team during the requirements phase by creating and presenting a risk profile for the application. The application's risk profile includes sensitive areas of the software, along with areas of the software that present attack surfaces that may be susceptible to certain attacks.

Such profiles also include high-risk areas of code that may be vulnerable to different threats. During the requirements phase, the critical step of documenting and establishing a risk profile helps to make security protocols, features, and methodologies transparent to software engineers. Risk profiles also help with the onboarding process for new team members.

Outline the Various Risk Categories, Such as Legal, Regulatory or Compliance

While creating and conducting comprehensive risk assessment, security engineers - during the requirements phase of the Secure SDLC - conduct the critical step of understanding, analyzing, and categorizing the various risks to the software application. During this process, it is helpful to categorize the various risks using a variety of security frameworks such as the OWASP Top 10, SANS CWE Top 25, or OWASP ASVS.

Planning and Design Phase

The Requirements Phase allows you to understand what the software needs to do to be both useful and safe, the Design and Planning Phase focuses on how you will do it.

Because the design phase of the Secure SDLC is the bridge between the what of the software functionality and the how - coupled with the fact that many security flaws in applications result from faulty design - it is imperative that the design phase is carried out thoroughly and with security in mind.

Within traditional Software Development Life Cycles (SDLC's) the planning and design phase is the step where architects and development teams determine how to implement critical features into an application. While the requirements phase decides the blueprint and what needs to be included in the software, the design phase determines how to implement those features into the application by planning a software architecture that will be implemented.

That said, traditional SDLC's move from blueprint establishment to the step of designing the architecture by first conducting a team-based analysis of application requirements. The user interface (UI) design, screen flow, positional structure of data elements on the screen, components and modules of the application, functions of the program, data calls, API calls, data storage, interactions between modules, etc. encompass the software architecture decisions that are made during this phase.

There are many different types of applications, and each will generally use different frameworks, models and programming languages for the purpose of meeting very specific business requirements, for example using Node.js versus Angular.js, utilizing Python versus Java in the backend, using Waterfall versus Agile models of development.

The design phase is where the programming language, model, and framework will be selected by the development team. When discussing software architecture, it is also important to understand the three-tier and four-tier application architectural standards, which represent the separations of processing between different organizational levels. A software package may embody a Web Application and a Mobile application, and may use the Representational State Transfer (ReST) network application architectural protocol that is often used for web services over HTTP. Typically, the client-server three-tier standard uses the presentation layer (e.g. associated with a web browser for a web application), application layer, and database layer - all built as separate modules - which presents the data to the end-user, processes data, and accesses the database.

Web applications and mobile apps that connect to online network systems often use ReST to provide web services and access to online resources. Database systems today are often relational database management systems (RDBMS) such as MySQL and Microsoft SQL Server, or NoSQL database such as MongoDB. Much like the OSI network model, software application tiers/layers work in concert to provide key functionalities to end-users.

Development Phase

The focus of a traditional Software Development Life Cycles (SDLC) is on quickly developing feature-rich, efficient, and productive applications.

They often put security issues in the background, which results in security vulnerabilities being found far too late in the post-production stages. Security planning needs to begin at the very root of the SDLC, during the requirements phase - which focuses on establishing the blueprint of the application and determining what features are required to be in the app.

Security also needs to be a primary focus in the design phase - which determines how to implement the required features - and the development phase - which is the actual coding phase that brings the requirements to actuality according to the blueprint and design specifications.

This means that the planning and preparation are done in the previous SDLC phases; in the development phase of the Secure SDLC all modules, components and architectural structures of the application are developed, and engineers don't have to make arbitrary assumptions about how to correctly implement security into the software.

The blueprint, implementation plan, and security strategies - based on risk management strategies, architectural risk analyses & threat modeling, etc. - set forth in the previous SSDLC phases - are a guide for software engineers to follow, such that the design and architecture of the finished product should be indicative of a secure system.

Verification of the application's security - as well as the secure coding of the application - are both necessary during the SSDLC, which not only ensures data security but also ensures that the application is meeting the business requirements and is in compliance with required legislation.

Vulnerabilities are Prevented Before They Can Occur

Traditional SDLC develop the code of the application without secure coding methodologies, often resulting in several high-risk vulnerabilities that need to be fixed later on in the production life cycle, which can increase corporate overhead and remediation costs.

This is a paramount point in software development as the number of vulnerabilities found in applications continues to grow exponentially. SQL Injection (SQLi) and Denial of Service (DoS) attacks were still among the top attack vectors and a large percentage of web applications scanned are still very vulnerable to cyber-attacks and exploits.

In contrast to such traditional development models, the fundamental paradigm of SSDLCs is that prevention is better than a cure, meaning that using secure coding methodologies during the development phase is significant in preventing the existence of high-risk vulnerabilities altogether, which can greatly decrease company overhead and save money.

In conjunction with using secure coding methodologies it is important to utilize code reviews and penetration tests during the life cycle of application development to ensure that code is secure before deployment in the production stages. Correcting and securing code before it is committed to code repositories is an important step in producing not only efficient but also secure code, and this method is also the cheapest way to address application security and a potential myriad of vulnerabilities.

Typical methods of securing the development process includes the use of peer code reviews, unit testing, and static code scanning and analysis. They often put security issues in the background, which results in security vulnerabilities being found far too late in the post-production stages. Security planning needs to begin at the very root of the SDLC, during the requirements phase - which focuses on establishing the blueprint of the application and determining what features are required to be in the app.

Security also needs to be a primary focus in the design phase - which determines how to implement the required features - and the development phase - which is the actual coding phase that brings the requirements to actuality according to the blueprint and design specifications.

This means that the planning and preparation are done in the previous SDLC phases; in the development phase of the Secure SDLC all modules, components and architectural structures of the application are developed, and engineers don't have to make arbitrary assumptions about how to correctly implement security into the software.

The blueprint, implementation plan, and security strategies - based on risk management strategies, architectural risk analyses & threat modeling, etc. - set forth in the previous SSDLC phases - are a guide for software engineers to follow, such that the design and architecture of the finished product should be indicative of a secure system.

Verification of the application's security - as well as the secure coding of the application - are both necessary during the SSDLC, which not only ensures data security but also ensures that the application is meeting the business requirements and is in compliance with required legislation.

During This Stage the Focus is on Security Unit Testing

During the planning and design phase, different modules and components of the software are planned out according to the original blueprint. During this subsequent development phase of the SSDLC, not only is the application coded but unit tests for each module and component are developed to continuously ensure application security.

Generally, traditional unit testing typically tests sections of software applications without security in mind, yet in the SSDLC this approach must evolve to include security unit tests of each module on a continuous basis. Furthermore, security unit testing must include very specific tests carried out on certain, critical units of the application such as authentication, session management, encryption, validation, encoding, and authorization services, all of which represent high-risk application areas.

At this stage of the development process the use of automated security unit testing is vital to assist engineers with securely coding the software application. This helps to eliminate common code vulnerabilities before the code is committed to repositories.

Additionally, engineers will be aware that writing insecure code will ultimately result in software builds that will fail unit tests, which helps to keep engineers focused on security concerns and on using secure coding best practices. The critical factor with SSDLC's is that security is always kept at the forefront of all software engineering activities.

Examples of security unit tests include:

• Logical checks of cryptography, session management, and authentication.
• Security Checks (e.g. access control, entitlement checks on unauthorized accounts).
• Defensive Code Checks with validation, encoding and error handling

Peer Reviews for Potential Vulnerabilities

A manual peer review process is best incorporated into the Secure SDLC to ensure an efficient system. This can be a process where reviews are assigned randomly to engineers before code is promoted or committed. Code review tools such as Gerrit can be used by reviewers, along with merge requests and pull requests to highlight changes that are suggested.

For high-risk code that performs security functions (e.g. authentication services, encryption modules, login and authorization services, session management components, etc.), this review process is critical.

In order for this process to be effective as a compensating security control, it is important for engineers who carry out reviews to be fully trained in secure coding methodologies and secure coding practices in order to fully identify weak code that could potentially be exploited.

Utilizing manual peer reviews is a security best practice that establishes separation of duties, prevents malicious code from entering production, and helps to mitigate malicious insider threats.

Using Static Analysis Testing During Development Not Just at The End

Automated scanning tools are vital to ensuring data security, in addition to peer reviews and manual tests that are carried out in the development environment. That said, it is important to integrate nightly security scanning for use with nightly builds - in conjunction with accurate scanning rules - to catch many critical vulnerabilities.

In order for such a practice to be used efficiently, scanners must be fine-tuned to eliminate as many false positives as possible, along with turning off low accuracy rules in order to carry out an accurate scan. This is significant since, at this point in the life cycle, engineers need to obtain critical information without being given nnew information that isn't pertinent to overall security.

It is imperative to tune scanners to output useful information so as to not increase time-consumption on unnecessary tasks. It is also important to note the different engines and parameters that scanners use, the latter of which include (but are not limited to): keyword searches, binary analyses, data flow analyses, structural analyses, and null pointer analyses. With this in mind, correct scanner parameters need to be used in order to obtain the most accurate and relevant data.

Automated Code Analysis Uncovers Vulnerabilities Earlier

While utilizing manual code reviews and testing is critical, using automated security testing during development can identify the most critical vulnerabilities that have plagued applications for decades – and continue to plague applications (e.g. SQL injection, Buffer Overflow, XSS, XSRF vulnerabilities) - before they reach code repositories. After the development phase, engineers move onto the verification & testing phase, which – when integrating security principles into the process – is a critical phase in the Secure SDLC.

Secure Your Software. Talk to us about building a Secure Development Phase.

Verification and Testing Phase

Verification and testing is an integral part of the software development life cycle (SDLC) in that it typically is the phase where software products are evaluated to determine whether they run as intended and meet user and customer needs.

Security checks and assessments are typically consigned to the verification and testing phase of traditional SDLC. A Secure SDLC contrasts greatly with traditional SDLCs by implementing security at every step of the development life cycle, such that security is built into the core foundation of the software, which leaves the verification phase of the SSDLC as an extension of previous security functions.

Run Time Verification Checks to Monitor Applications for Security Flaws

While security assessments, security analyses, and peer code reviews are done during previous phases (such as the development phase), it is often the case that vulnerabilities are missed during such phases. The verification testing phase is a step encompassing a more thorough, robust testing procedure, often during run-time in order to more comprehensively monitor software applications for security holes.

This includes automated testing of security functionalities, i.e. Authentication, authorization, session management, encryption, access control, validation, and encoding. An example includes whether a user with a standard (non-admin) account should only have access to user-level pages and APIs.

Automated testing should ensure that said user does not have administrative access or access to management sections of the system, and that any attempt to access such root systems results in an “unauthorized” error. The utilization of automated testing is pivotal in ensuring that all application procedures for user access to correct endpoints work as expected.

Automated non-functional testing is also used during this phase to verify secure server configuration and that TLS is securely configured for proper encryption of data in flight.

Dynamic Analysis of the Application Before Releasing for QA Testing

The use of lightweight, dynamic scanning and testing software is typically introduced in the verification phase of the Secure SDLC in order to scan for known vulnerabilities. While static code analysis generally scans the code and searches for known security holes, dynamic tools can help determine whether the application implementation is secure. In order to be efficient and productive such scanners need to run quickly, not require too much maintenance or overhead, and should result in a low number of false positives.

The latter is a very significant point as a scanner loses its efficiency when engineers receive data indicating that multiple security holes exist where there are none. There are many powerful, lightweight, and efficient scanning tools that exist, such as ZAP and Arachni, which can operate in conjunction with continuous integration testing tools such as Gauntlt, BDD Security, and Selenium, to automate a dynamic scanner in head

Automated Dynamic Scans in the Nightly Builds (CI Pipeline)

There are many valuable testing methods associated with automated scanning and testing. Blackbox testing and fuzzing are two such tests that are often conducted during the verification phase. Because vulnerabilities are exploited via user inputs - which manipulate a system to react in ways that a developer didn’t intend or expect - it is important to test a variety of inputs against a system to determine how the application can potentially be exploited.

It is also important to note the difference between verification security testing and QA testing; while QA testing focuses on using “positive” inputs to determine whether a positive, expected output results, fuzzing and similar tests focus on utilizing malicious inputs to establish whether an attacker’s inputs could have malicious results.

With an efficient CI pipeline in place, results can be fed back to engineers using ticket systems (e.g. JIRA, Git, etc.) as tasks and builds finish, which eventually result in a complete feedback loop for all identified issues for the software in production. The next step in the SSDLC is the release phase, which often includes maintenance and support of the application.

The Release Phase

The release phase of the Software Development Life Cycle (SDLC) is traditionally associated with production, deployment, and post-production activities. Which generally include maintenance and support of the software that has been developed.

In this phase, post-production tasks (after deployment) in traditional SDLC models do not greatly involve development engineers. Operations admins and security engineers typically complete most of the functions, which may include software monitoring, security testing, incident response and other things.

In the Secure Software Development Life Cycle (SSDLC), developers are responsible for completing additional security tasks, which - even in the post-production stage of the release phase - integrates security with development. Other factors associated with the release phase include:

• Confirming that the software works as optimally in the production environment as it did in the development environment
• Obtaining feedback from end-users in order to make appropriate tweaks
• Conducting maintenance and support tasks
• Verifying that the software in production meets customer and user needs according to the initial requirements.

With Continuous Monitoring and Logging of the Software, Stay Ahead of Cyber-Criminals

The release phase of the SDLC is composed of many maintenance tasks, and thus it is a continuous process. Security itself is a continuous process of testing, upgrading, patching, maintaining & remediation tasks to ensure that software continues to remain secure and available. That said, in the Secure SDLC engineers are responsible for additional tasks not typically associated with SDLC models of development, including adding application logging events for security purposes. The security-based software events that should be logged include:

• Login events (successes and failures) • Authorization events (successes and failures) • 4xx errors (client errors) • 5xx errors (server errors) • Database syntax errors • Access control exceptions • Validation errors • CSRF token validation errors

It is important to note that certain models and methodologies of software development, such as DevOps - which often seeks to incorporate security testing into various stages of the SDLC - integrates the various tasks associated with developers, QA testers, operations admins, and security engineers throughout the entire life cycle, and thus increases collaboration throughout software development.

In the release phase of the SSDLC, development engineers are responsible for ensuring that critical application processes and events are logged and consequently work closely with operations admins and security engineers.

Using Monitoring Tools to Watch for Security Events and Trends for Attack Signatures

One of the most critical tasks that engineers need to accomplish in the SSDLC is to monitor applications and obtain metrics that can help to identify security threats. Data, such as metrics and attack signatures, can be correlated with certain logged events to help operations and security teams mitigate security threats before they become full data breaches.

Monitoring tools, such as StatsD, Graphite, Grafana, Splunk, and Loggly are used to gather and aggregate stats and data on security events. In addition to aggregating data and metrics, patterns & attack signatures should be visualized via real-time graphs to better understand the nature of threats to the application in the production environment. Measuring and building graphs is a key step in helping to mitigate future threats.

A simple chart or graph illustrating all successful login attempts versus failed login attempts, where a brute force attack against the login page would result in a massive spike in failed login attempts can successfully alert teams of an attack occurring in real time. Visualizing data & metrics is a powerful method of aiding teams in mitigating security threats.

The proper utilization of security metrics is key to efficiently equipping engineering teams and admins with the information needed to mitigate security threats. To this end, metrics should be made transparent to the project team - and for the sake of educating all personnel, the entire organization - to ensure that all personnel are aware of the hostile production environment that the application has been deployed in.

Correlation Between the Logs and the Traffic Information Available

Establishing an efficient defensive front based on attacks (i.e., an attack-driven defense) allows for the implementation of a powerful system that combines event/log metrics and real-time traffic data, the correlation of which can be used to detect attacks as they happen in real-time based on the aforementioned attack signatures.

With such an infrastructure in place, a feedback system can be incorporated allowing data to be fed back to engineering and admin teams. These teams can create additional security dashboards and sub-systems that permit incoming attacks to drive a variety of powerful defensive countermeasures.

The utilization of a security dashboard based on security data is significant in that such a system can be used to identify additional attack signatures in real time, i.e. abnormal traffic volumes often associated with fuzzers, scanners, DoS programs, etc. Additionally, attack patterns and signatures can be used as grounds for modifying code in order to stop exploits from occurring, and can be used as a foundation for pre-empting future threats based on known vulnerabilities. In certain environments, such as a Secure DevOps environment, such modifications can be made in a matter of minutes in order to close security holes and mitigate software vulnerabilities.

Monitor 3rd Party Libraries for External Vulnerabilities

In the software engineering industry, whether using SDKs (Software Development Kits) or Open Source code repositories, the use of third-party libraries is ubiquitous. In fact, 3rd party software may comprise up to 80 percent of an application. It is typical for open-source or vendor code - that makes up a large percentage of the code running in production - to contain vulnerabilities. It is important to monitor third-party code in order to protect your software from attacks due to a known vulnerability being present.

In fact, the risk associated with using software containing known vulnerabilities is number nine in the OWASP Top 10, which comprises 10 critical web application flaws and unsafe practices that can result in a data breach. The SSDLC process should include the use of continuous monitoring tools (e.g. OWASP Dependency Check) across the entire software supply chain to ensure that all code in use is vulnerability-free.

Both automated scanners & manual penetration tests are needed to ensure that code is truly devoid of the OWASP Top 10 and CWE 25 vulnerabilities. Another key step in maintaining secure coding systems is the establishment of an internal, secure code repository that includes code libraries that have been thoroughly reviewed, scanned, and approved by security teams.

When protocols are set in place to allow development engineers to utilize only approved libraries and versions it is more feasible for teams to monitor them for vulnerabilities and security holes.

To ensure that this system is effective, all new versions and libraries should be scanned and approved by the security team before introducing them to the package repository. This robust system can help to ensure that only secure code is used in your software applications and that insecure code is not being deployed into the production environment.