New Bootstrap vulnerabilities could spell trouble for those with websites or web apps running Bootstrap 3 or Bootstrap 4, which are end of life and no longer community-supported. 

Keep reading to find out how these vulnerabilities can be exploited to engineer cross-site scripting (XSS) attacks and what to do to enhance your Bootstrap security. 

Recently Disclosed Bootstrap Vulnerabilities: Who Is Impacted?

AngularJS has been end of life (EOL) since 2022, and yet more than 20% of large enterprises have not yet migrated to a different framework*. Usually when software becomes end of life, there is a clear successor, but that’s not exactly the case with AngularJS. 

In this blog, we explore how to choose a JavaScript framework to replace AngularJS, with overviews of the most popular JavaScript frameworks as well as different ways to approach your AngularJS migration.

*Source: 2024 State of Open Source Report

Why Replace AngularJS?

As just mentioned, the main reason to replace AngularJS is because it is end of life. This means no more updates, bug fixes, or security patches are being issued from the community. Staying on EOL software exposes your application(s) to vulnerabilities that can be exploited — resulting in serious fiscal and/or reputational damage that puts your business in the headlines for all the wrong reasons. 

Read more about AngularJS vulnerabilities >> 

While security is the most important consideration here, it’s not the only reason to get off AngularJS. New browser versions and updates to jQuery can also wreak havoc and cause breaking changes and downtime. As an older framework, compatibility is another potential problem. As the web development landscape continues to evolve, there is a good chance AngularJS will not always integrate seamlessly with the latest and greatest tools and libraries. 

Back to top

Key Considerations for Choosing a JavaScript Framework

In general, assessment in three key areas is important as you evaluate AngularJS alternatives: scalability, community, and learning curve.

Scalability: Scalability should be one of your top concerns when selecting your next JavaScript framework. Think about your project’s size and complexity, as well as future plans for growth. You need a framework that can scale as your business scales. 

Community: The landscape of JavaScript frameworks has grown over the years, but not every project has been widely adopted or proven stable enough to be viable for enterprise. How established is the community? Can you rely on them for support or guidance if you need it? An active community means there will likely be regular updates, bug fixes, and a robust ecosystem with tools and documentation. 

Learning Curve: Before adopting a new framework, it’s a good idea to consider how long it will take to learn and your dev team’s current expertise. Is your team already familiar with the framework’s concepts and syntax? Obviously, choosing a framework that is aligned with your team’s existing skills can speed development.

Back to top

Popular JavaScript Frameworks 

Let’s take a look at a few of the top JavaScript frameworks for frontend development that could be suitable replacements for AngularJS. We’ll focus on how they compare to AngularJS in terms of architecture, DOM, and data-binding, and highlight some benefits and drawbacks. 

Angular

Angular is written in Typescript, which is a superset of JavaScript, so migrating means committing to coding in Typescript moving forward, which may extend the learning curve. Angular does, however, have interoperability with AngularJS, so an upgrade via ngUpgrade is possible. The architecture of Angular is also different from AngularJS: Angular’s component-based architecture (compared to AngularJS’s model-view-controller, or MVC, architecture) is a better fit for mobile-first development and makes it very scalable, due to reusable modular components that simplify the development of complex applications. 

Learn more about Angular vs. AngularJS >>

ReactJS

ReactJS was developed by Facebook and offers a component-based architecture like Angular. While AngularJS is MVC, ReactJS is just V, or View-based, and can be used to build dynamic user interfaces. The biggest difference between AngularJS and ReactJS is their scope: AngularJS is more broad and feature-rich, whereas ReactJS is more narrow in scope, making it lightweight and flexible. AngularJS also relies on the real DOM, which can slow things down compared to virtual DOM frameworks like ReactJS and VueJS. 

Read more about AngularJS vs. ReactJS >>

VueJS

VueJS is known for its versatility and intuitive syntax, making it easy to learn. Like ReactJS, it is lightweight with a small API footprint and focused on the “view” part of the typical MVC architecture. VueJS supports two-way data binding, similar to AngularJS, but discourages it in favor of one-way data flow, which is more flexible. Many developers find it easy to get started with VueJS, but before migrating, be sure to consider how your AngularJS deployments are using behaviors from the AngularJS ecosystem.

Get a more in-depth comparison of AngularJS vs. VueJS >>

EmberJS

Compared to the lightweight simplicity of ReactJS and VueJS, EmberJS is more “complete” and well-suited to complex, high-traffic mobile or desktop applications. It follows the MVVM (model-view-view-model) architecture, and components cannot be reused. Compared to AngularJS’s modular approach, EmberJS utilizes routers, templates, models, and components. While two-way data binding is preferred according to the documentation, one-way data binding is also supported. EmberJS uses a rendering engine called Glimmer, which behaves similarly to a virtual DOM. 

Explore more differences between AngularJS and EmberJS >>

Back to top

Planning Your AngularJS Migration 

Both the choice of framework and migration strategy is likely going to be informed by how you/your stakeholders prioritize quality, time, and cost. In the ideal-but-unlikely scenario that you have unlimited money and unlimited time, you won’t have to sacrifice at all in terms of quality. However, most teams will have to make decisions based on tight deadlines and budgets. 

Questions to Answer Before Migrating

As with any legacy codebase modernization project, you should start by analyzing things like size, complexity, dependencies, and your dev team’s bandwidth. Answering the following questions is a good starting point: 

Once you’ve answered these questions and chosen the framework to replace AngularJS, you’re ready to plan the migration itself. There are essentially two approaches:

1. A phased migration, aka gradually replacing AngularJS components with the new framework. Depending on your application, this can be technically challenging, but it can be done. It may require partnering with a commercial vendor for long-term support (LTS) for your existing system while you migrate and/or expertise to guide the migration itself. 
    
2. A complete rewrite, aka rebuilding the application from scratch on the new framework. This can be both time- and resource-intensive; on the other hand, a rewrite could unlock opportunities for a new version with a different vision.

There are some tools that can help automate refactoring, analysis, and running codemods, including ngMigration Assistant, Jscodeshift, and TSLint. The open source community for your new framework may also be able to offer tips and support, or you could consult with OpenLogic for help building your migration roadmap. OpenLogic also offers AngularJS LTS through 2030 if you need a source for patches while you rewrite or migrate your system. 

Back to top

Final Thoughts

Make sure to conduct thorough testing and debugging before implementing the new framework in a production environment, as there may be unforeseen compatibility or integration issues. Also be prepared to offer whatever additional training or upskilling your team needs so they can fully take advantage of the new framework’s capabilities. Finally, after migrating, don’t forget to continually monitor performance via metrics like page load speed, network requests, and rendering, so you can optimize as necessary to keep your application running efficiently. 

MINNEAPOLIS, SEPTEMBER 17, 2024 – Perforce Software, the DevOps company for global teams requiring speed, quality, security and compliance at scale along the development lifecycle, today launched its annual survey exploring open source software (OSS) usage in organizations worldwide. The survey’s findings will be the foundation for the 2025 State of Open Source Report, which offers a comprehensive assessment of the current landscape of OSS technologies and trends. This year’s survey was developed through a joint effort led by OpenLogic by Perforce in collaboration with the Eclipse Foundation and the Open Source Initiative (OSI). 

“We are delighted to partner once again with both the Eclipse Foundation and Open Source Initiative,” said Tzvika Shahaf, VP of Product Management at Perforce. “This year, we have added a new section on Big Data infrastructure, since data technologies was identified as one of the biggest areas of investment in the 2024 report. We hope to gain a better understanding of how enterprises are managing their Big Data stacks and the challenges they face.”

The survey, which will close on November 1, asks questions related to the day-to-day use and management of OSS, as well as governance and maturity. Response data will be compiled into a detailed report, with sections focused on different technology categories (i.e. operating systems, databases, programming languages) and topics such as security and compliance. 

The Eclipse Foundation is proud to participate in the 2025 State of Open Source survey and report. We view it as essential to our work of championing open source development and innovation,” said Thabang Mashologu, VP of Community and Outreach at the Eclipse Foundation. “The State of Open Source Report always provides invaluable insights that enable us to better support our community of open source contributors and organizations that rely on OSS for their business-critical applications.”

Since it was first published in 2019, the State of Open Source Report has been cited in numerous industry reports, as well as shared at top open source conferences around the world.

“This is our fourth year being involved in the State of Open Source Report, and there is never any shortage of surprises in the data,” said Stefano Maffulli, Executive Director, Open Source Initiative. “Now, however, the aim of the survey is not to determine whether or not organizations are using open source — we know they are — but to find out how they are handling complexities related to AI, licensing, and of course, security.”

Anyone using open source in their organization is invited to complete the 2025 State of Open Source Survey. 

Linux security is top of mind these days as CentOS Linux, one of the most popular open source Enterprise Linux distributions, just sunsetted its final version. No more updates or patches will be released from the community, and it is estimated that there are still tens of thousands of servers running end-of-life CentOS. 

Whether you are still on CentOS or on another Linux distro, knowing how to secure your Linux server is essential to protecting your systems and keeping unauthorized people and malicious code/malware out.

In this blog, read about Linux security best practices, including some setup/configuration “shortcuts” that can actually weaken your security and increase your risk.

Linux Security: Overview

There are many reasons why you should (or must) secure your Linux servers, but the top two that immediately come to mind are compliance and accountability. 

Compliance Requirements

There are a number of scenarios where securing your Linux server is mandatory. For example:

• If you process or store any credit card information, there are requirements to secure your server.
• If you handle medical data, there are HIPAA security requirements.
• You may have security policies within your company that you need to adhere to.
• If you interface with 3rd parties, there may be security agreements that all parties need to comply with.

If any of the above apply to your organization, securing your Linux server is not optional. 

Get more information about open source compliance >>

Accountability

• Having tight security can furnish you with favorable answers when prospects or customers ask about your company’s security history, which is far better than the alternative (aka having a bad reputation due to lax security).  
• If a security issue does occur, your company could be legally liable to have implemented certain security measures. 

Regardless of why you feel it is necessary to keep your Linux server secure (or how you justify it to others in your company), properly implemented Linux security measures will undoubtedly benefit your business beyond any potential inconveniences that may come to mind when security is mentioned.

Back to top

Common Linux Security Vulnerabilities 

When most people think about Linux vulnerabilities, they think of bugs in software which can result in potential security risks. Recently, CVE-2024-6387 and CVE-2024-6409 were disclosed, and both are vulnerabilities within the OpenSSH package on EL9 (and EL9-based distributions). Very few systems use insecure remote access methods like Telnet these days, but it used to be that you had a choice of having the default Telnet access and/or installing SSH. Luckily, SSH became the default for remote access, but it is still necessary to keep it up-to-date in order to continue enjoying the security that using it provides.

Security vulnerabilities can show up in almost any package. For instance, CVE-2021-43527 is a CVSS score 9.8 remote code execution vulnerability in nss, CVE-2022-25315 is a CVSS score 9.8 overflow/DoS/arbitrary code execution vulnerability in expat, and CVE-2021-35942 is a CVSS score 9.1 overflow/arbitrary memory read vulnerability in glibc. Last year, the high severity Looney Tunables vulnerability (CVE-2023-4911) impacted numerous Linux distributions including CentOS 8, and a critical libwebp vulnerability (CVE-2023-4863) allowed essential heap data structures to be overwritten in CentOS 7 and 8, as well as other open source software that uses the popular code library (NGINX, WordPress, Node.js, and others). 

Note: OpenLogic provides CentOS patches for CVEs with CVSS score of 7 or higher for our CentOS LTS customers.

Vulnerabilities (and the bad actors that exploit them) are somewhat beyond our control — but there are other things that can weaken Linux security we can address. I’m talking about choices that get made to save time/effort and make implementation easy, or issues that are do not seem high priority enough to get taken care of in a timely manner. 

Here are a few examples:

• Using passwordless ssh keys so you don’t have to type your password over and over each day or having the system auto-login when it boots (“Nobody is allowed to touch my workstation.”)
• Leaving root logged in at the console (“I’m the only one who comes into the data center.”)
• Turning off SELinux (“It’s too difficult to get it working properly.”)
• Not updating some or all of the packages on a system (“It’s working right now and I don’t want to risk breaking anything.”)
• Leaving accounts on a system after an employee has left the company (“They can’t get into our network anymore so there’s no rush to remove their accounts.”)
• Keeping mission-critical systems running on End-of-Life distributions (“I have too many other things on my to-do list and these have been working just fine for years!”)

Main point: cutting corners when it comes to Linux security is never a good idea and can come back to haunt you.

Back to top

8 Steps to Secure Your Linux Server

In addition to not doing any of the shortcuts above, here are 8 best practices that you should consider:

1. Harden systems to specific security standards (CIS Benchmarks, PCI-DSS, STIG, etc.) 

Even if there aren’t any explicit requirements to do this, it’s a good idea. This can be made easier by using pre-hardened images. These images can either be created in-house or obtained from a trusted 3rd party like OpenLogic.

Most benchmarks will test and configure the system through hundreds of checks, such as automatically disconnecting idle sessions, and raise flags if auto-login is enabled, or accounts without passwords are detected, and so on. 

    2. Use (and require) strong passwords

Social media is filled with fun little quizzes about your pet’s name, your childhood address, what year you were married, and so forth. First of all, don’t fall for these social engineering tricks that try to get you to share information commonly used in passwords or security questions. If you do accidentally share info like this, a strong password means hackers won’t have enough information to easily figure out how to access your accounts.

Security benchmarks typically configure the system to enforce this, too.

    3. Keep systems updated

You not only need to keep the OS updated but also all of the apps (and any dependencies) on the system.

The fear of breaking something due to an update can be alleviated by having a lab/staging environment where you can test updates (and other changes) in isolation before deploying to production.

If a lab/staging environment is not available, consider a phased deployment to a few systems that, if problems occur, can be taken offline, repaired, and then brought back online.

    4. Plan to migrate systems before they reach end of life (EOL)

True Enterprise Linux distributions have known lifecycles from release through end of life. This information can be used to plan when to upgrade from one OS to another from the start instead of near (or after) the published EOL date.

If they do reach EOL, procure long-term support for the OS and packages/services (such as the CentOS support available from OpenLogic for 5 years after the EOL date).

    5. Implement MFA (Multi-Factor Authentication)

MFA adds another layer of access security for each account so a misplaced Post-It note with your new password on it or a lost thumb drive that contains an SSH key doesn’t automatically allow access to whomever sees/finds it.

    6. Use system configuration to deploy and validate configuration and security consistently

Not only can tools like Ansible or Puppet help with the initial launch of your systems, they can also be used to maintain ongoing compliance and updates of those systems, and reduce MTTR in Disaster Recover (DR) situations in the event that systems need to be rebuilt from scratch.

Comparing configuration management tools for enforcing Linux security? Here’s what to know about Ansible vs. Puppet >>

    7. Incorporate SELinux from the start (and don’t disable it or leave it in passive mode)

The most common SELinux-related problems that are difficult to resolve are due to development and testing (and sometimes, staging) being done with SELinux disabled and the placement of files and directories being where SELinux doesn’t know how to handle them. Then, when SELinux is finally enabled (typically in staging but sometimes in production), everything breaks and SELinux is disabled again and left that way. By placing your files in locations that adhere to SELinux’s expectations, local SELinux policies can be minimized or eliminated.

    8. Stay on top of account maintenance

By incorporating centralized authentication such as some combination of FreeIPA, Directory Services, SSO, Kerberos, and RADIUS, it becomes very easy to activate, deactivate, or update accounts and their permissions. Most high-end network gear also supports centralized authentication so your entire infrastructure can be secured the same way.

If you don’t have centralized authentication, use tools (like the aforementioned Ansible or Puppet) to keep accounts stored locally on each system in-sync.

Back to top

Final Thoughts 

Unfortunately, there is no shortage of bad actors looking to compromise your system to steal data or otherwise cause harm to your business. Having a secure Linux server and strong Linux security measures means you can sleep well at night because you’re not worried about all of the potential attacks that you have no defenses against, and you’re not prepared for.