devopsy.kinsta.cloud

Category: Blogs

  • IBM Unifies Cloud Services to Simplify App Dev

    IBM Unifies Cloud Services to Simplify App Dev

    IBM announced today that an IBM Cloud Code Engine service that unifies the cloud platforms on which applications are built and deployed is now generally available.

    Built on top of a serverless computing platform, IBM Cloud Code Engine is a managed service that unifies access to a platform-as-a-service (PaaS) environment, a container-as-a-service (CaaS) environment and batch workloads, that run on traditional virtual machines, to a single platform.

    At the core of that managed service is an instance of Kubernetes running Knative middleware for invoking an open source serverless computing framework, the Istio service mesh and Tekton pipelines for building DevOps workflows.

    Jason McGee, CTO and vice president for IBM Cloud Platform, said the goal is to eliminate the artificial constructs that developers are forced to navigate in the cloud today that can each trace their lineage to a different era of software development. The IBM Cloud Code Engine unifies the developer experience in a way that makes it simpler to build and deploy applications on the type of cloud service that best makes sense for a specific application workload, McGee said. Developers no longer need to configure code for a specific type of infrastructure; they can simply describe how they want source code or a container image to behave, and IBM Cloud Code Engine automates deployments accordingly.

    The serverless computing framework that IBM Cloud Code Engine is built on also makes it possible for IBM to only charge organizations when code is actually running, versus requiring them to commit to a specific amount of infrastructure to run a set of virtual machines, McGee added. Charges are based on the memory and vCPU consumed and incoming HTTP calls. That approach will, over time, substantially reduce the total cost of cloud computing, said McGee.

    It should also accelerate the rate at which applications are migrating to the cloud, added McGee. Today roughly 20% of application workloads run in the cloud. Getting the next 40% of workloads shifted into the cloud will require providing a simplified application developer experience, noted McGee.

    The challenge organizations are wrestling with today is that they are deploying a mix of monolithic and microservices-based applications in the cloud that, to varying degrees, rely on batch-oriented and real-time platforms. IBM Cloud Code Engine represents an effort to provide a layer of abstraction over a wide range of cloud services that they can flexibly invoke via an event-driven platform, as required.

    The DevOps implications of IBM Cloud Code Engine are potentially profound. DevOps teams today spend an inordinate amount of time provisioning cloud infrastructure on behalf of developers. IBM is now making a case for a platform that automates that process in few seconds. In effect, control over cloud infrastructure will shift even further left to application developers. DevOps teams, in theory, will spend more of their time optimizing cloud environments after an application has been deployed.

    It’s not clear to what degree platforms such as IBM Cloud Code Engine might force cloud service providers to consolidate distinct cloud services they provide to developers today based on the type of application being built. However, it’s already apparent that the writing on the wall heralding that consolidation have now been indelibly inscribed.

  • How to Modernize Data Integration

    How to Modernize Data Integration

    In times of uncertainty, accurate real-time data becomes essential to informed decision-making. When the pandemic ends and businesses begin to reopen, this will be truer than ever. While there is no precedent for COVID-19’s impact on the economy, what is clear is that the enterprise is clamoring for more analytics than ever. Data engineering is at the heart of operationalizing the delivery of that data, wherever it originates and wherever it’s needed.

    To operationalize data flows, engineers must be able to collaborate with different personas, reuse peer assets, support data pipelines in production and, as platforms and business requirements change, evolve quickly and with confidence. The focus of data engineering can no longer be limited to ease-of-use and developer productivity. In today’s fast-changing world, we need to enable modern engineers to embrace DataOps. In doing so, they will be able to guarantee continuous data for fast, confident decisions by and for the business.

    Current Options Are Too Simple or Too Complex

    Current approaches follow either a “grab-and-go” mentality that focuses on simplifying ad-hoc access for first-time analysis, or lurches towards specialized coding for anything complex. Both of these approaches lead to ongoing and recurring headaches. Significant effort is required to debug data pipelines, rerun them and rework them every time a change happens. Today’s data engineers end up spending 80% of their time just keeping the lights on, leaving very little time for new value-added work.

    Using Intelligent and Responsive Data Pipelines

    Data engineers face mounting pressures and challenges, from an ever-increasing project backlog to an accelerating pace of upstream changes to the emergence of cloud data platforms driving re-platforming projects. To tackle these issues, engineers need a solution that allows them to operationalize their work by abstracting the “what” of the data—the business meaning and the logic—away from the “how” of the data—the technical implementation details that the business doesn’t care about. To achieve this, businesses need to think about data pipelines as dynamic, intelligent sources that can (and should) be capable of real-time adjustments.

    There are three ways that data pipelines can be considered smart or dynamic: they are easy to start and easy to extend; they are resilient to changes that occur over time and they are portable, supporting hybrid and multi-cloud environments.

    Companies that have focused on removing the “how” by developing intelligent and responsive systems free up their engineers to stay focused on the “what” – what are the outputs? Are the analytics providing the right ROI or information? They also make it easy to get started building pipelines through intent-driven design, removing tedious tasks for engineers and empowering ETL developers to self-service. This includes the repetitive task of managing data drift, whether it’s a schema change, a database version upgrade or a file format change. Smart pipelines handle such changes with minimal to no intervention required.

    Demand Continuous Data for the Business, Now

    COVID-19 has segmented businesses into have-lots, haves and have-nots. The have-lots have experienced unimaginable growth and, consequently, are generating incredible amounts of data. They have had to deliver better engagement with their constituents, optimize their product offerings and stop bad actors, fraudsters and cybercriminals from exploiting the unexpected surge in demand for their business. If they have risen to the challenge, you can bet that they have modernized their data practice and can deliver continuous data to all consumers.

    The haves and have-nots have generally been in survival mode, operating under short-term mindsets to reduce cost, consolidate as much as possible and wring out any waste. Depending on each individual situation, that may have meant staying on legacy platforms and postponing modernization efforts. Some have enjoyed cost savings by reducing consumption and negotiating with their vendors. Others have made a tactical move to the cloud, but simply as a path to lower costs of their data platforms. Only a select few have done the right thing and made the complementary investments in data engineering to reap the full benefits of their shift to cloud.

    As this pandemic comes to an end, the prospects for the haves and the have-nots will start to look more promising. If you have been focused solely on keeping the lights on and managing costs, you may have been mortgaging your future. This needs to end. Don’t wait. By modernizing your ETL to create more dynamic, real-time data pipelines now, your engineers can operationalize their work, deliver a new level of innovation and self-service to the business and demonstrate their true worth as data heroes.

  • In the Club

    In the Club

  • Oracle Extends Capabilities of Enterprise Manager Platform

    Oracle Extends Capabilities of Enterprise Manager Platform

    Oracle today announced it has updated its core management platform to provide capabilities that make it easier to manage a hybrid cloud computing environment spanning millions of endpoints.

    The latest release of Oracle Enterprise Manager (EM) 13c, in addition to greater scalability, also provides support for dynamic groups, dynamic runbooks, automated workload analysis, monitoring templates, event compression and other capabilities that make it easier to manage IT operations at scale.

    Oracle Enterprise Manager (EM) 13c Release 5 also extends the reach of the management platform further into the realm of packaged Oracle applications and integrated hardware and software platforms such as Oracle Exadata, Oracle Database Appliance (ODA), Zero Data Loss Recovery Appliance (ZDLRA) and Private Cloud Appliance (PCA).

    Oracle has also updated the compliance framework it includes with Oracle Enterprise EM to support additional regulatory requirements and refreshed the user interface for the fleet management tool provided.

    Finally, the company is adding a tool that makes it easier to copy data stored within Oracle EM 13c to the Oracle Cloud Infrastructure (OCI) service. Dubbed OCI bridge, this tool copies data to an OCI object store where it is accessed by OCI services such as logging analytics and operations insights.

    Mughees Minhas, vice president of product management for enterprise and cloud manageability at Oracle, said as hybrid cloud computing continues to evolve, the need for a single management platform that spans infrastructure, databases and applications is becoming more apparent.

    Minhas said Oracle EM 13c is part of larger observability initiative that Oracle has embraced to provide more context across disparate services in a way that reduces the total number of tools an IT team needs to deploy and master. That effort complements a series of autonomous computing initiatives Oracle has previously launched that eliminates the need for database administrators (DBAs) to manage lower level systems administration tasks such as performance tuning. In general, Oracle is making a case for an IT world where platforms are co-managed by Oracle and internal IT teams that are focused on higher-level tasks.

    As IT environments become more distributed it’s clear IT is becoming more complex to manage. The issue that IT teams need to come to terms with is to what degree can they automate management tasks that today conspire to limit the size of the IT environment any given IT team can effectively manage. DevOps teams, of course, have been ruthlessly automating application development and deployment tasks for years. That philosophy is now being extended to include a broader range of IT operations tasks being automated by vendors themselves.

    Each IT team will ultimately need to decide just how many automation platforms it requires. In many cases, IT teams are now struggling to unite various islands of automation that have now emerged within their organization. Regardless of approach, however, rote tasks that once consumed hours, sometimes days to complete, are now no longer required which, theoretically at least, should leave more time to focus on more complex challenges that are getting thornier by the day.

  • Red Hat Extends Reach and Scope of Insights Analytics Service

    Red Hat Extends Reach and Scope of Insights Analytics Service

    During its online Red Hat Summit event, Red Hat today announced it has extended the Red Hat Insights predictive analytics cloud platform for managing IT to now include support for editions of Red Hat OpenShift based on Kubernetes and the Red Hat Ansible Automation Platform.

    In addition, Red Hat has extended Red Hat Insights for Red Hat Enterprise Linux (RHEL) to include the ability to prioritize security alerts, streamline notifications and track Red Hat subscription consumption.

    In total, since launching Red Hat Insights in 2019, Red Hat claims there are now more than 600,000 RHEL hosts analyzed per day.

    Joe Fitzgerald, vice president and general manager for the management business unit at Red Hat, said Red Hat Insights provides IT teams with the equivalent of a co-pilot for managing IT environments. In general, advances in automation and artificial intelligence (AI) are making it easier to manage complex IT environments at scale, noted Fitzgerald. However, it’s not likely IT environments will be automated to the point where lights-out management without human intervention is likely to be achieved any time soon, added Fitzgerald.

    However, it’s also becoming apparent that it’s not possible for IT teams to manage complex IT environments without help in the form of advanced analytics tools. In fact, while many IT professionals are leery of automation tools because of the perceived threat to their jobs, it’s also becoming apparent that IT teams will not be able to manage modern IT environments without these tools. Organizations can’t afford to hire small armies of IT personnel. In addition, finding and retaining IT professionals that have, for example, Red Hat OpenShift skills remains a significant challenge.

    Red Hat Insights provides IT teams with additional levels of context required to manage these environments that goes beyond simple monitoring, noted Fitzgerald. That’s critical, as the IT environment becomes more extended in the age of hybrid cloud and the rate at which platforms are updated steadily increases, added Fitzgerald. Platforms such as Red Hat OpenShift, for example, are now typically updated every three to four months.

    DevOps, of course, has always been about ruthlessly applying automation whenever possible. As analytics applications become more robust, IT teams gain the visibility required to automate a wider range of complex tasks, noted Fitzgerald. In fact, in the absence of that visibility, automation can be a dangerous thing when mistakes caused by a lack of visibility and insight are made, added Fitzgerald.

    In the longer term, Red Hat expects to see continued convergence of job functions and roles as IT teams become more cross-functional, said Fitzgerald. Platforms such as Red Hat Insights will provide a single console around which these teams can collaborate, added Fitzgerald.

    Going forward, there won’t be a handful of administrators with augmented capabilities. Rather, IT specialists that have a particular set of skills will be able to collaborate more easily in a way that both creates a better outcome and ultimately keeps a lid on the total cost of IT.

  • Are Developers Responsible for Open Source Governance?

    Are Developers Responsible for Open Source Governance?

    There are lots of factors in the open source software world converging to make it a big year for “shift left” in software development. Heightened security concerns, an increasing need for software supply chain visibility and the growth and complexity of open source ecosystems will continue to push the responsibility for ensuring code is secure earlier in the engineering process as far left as the request and design phases.

    This means 2021 will be yet another year in which developers are challenged to take on more responsibility, and pushed further onto the front lines of open source governance. Developers will need access to the right training, resources and tools to do this job. But they also can’t be successful if they’re expected to do it alone. Shift left can’t mean shifting all responsibility to the developer as the sole protector of secure code and the only go-to open source expert. The reality is that the depth, breadth and complexity of open source governance in 2021 demands a cross-functional team and layered approach.

    Equipping Developers With Governance Knowledge

    Let’s start with how to better equip developers and other stakeholders in the governance process, including legal, security, IP compliance and product people. These teams need enough knowledge to be aware of the top compliance issues, and their corresponding remediation options, to be active contributors in this rapidly evolving space. Research from Forrester shows that of the top 40 computer science programs in the United States and the top five programs internationally, none include open source licensing and security coding practices in the curriculum.

    Instead, it has fallen to the industry itself to impart this expertise on the job. Leading companies are packaging open source training programs into something that resembles standard HR-led and managed training, including check-ins and quizzes to test and solidify knowledge, and regularly updating content and scheduling trainings to make sure people stay abreast of changes and challenges. In the spirit of open source, many industries work collaboratively to share best practices on governance in this regard, with industry experts speaking on the topic at other companies. Others are leveraging existing management training courses, such as the ones offered by the Linux Foundation.

    The growing importance of the Software Bill of Materials (SBoM) also points to the need for cross-functional collaboration. Software supply chain visibility will become even more crucial in 2021 so that companies can build and sell secure and safe products, as well as ensure compliance. More people across the organization will need to access and view the SBoM in ways relevant to their functional needs. As a result, its assembly is transforming from being assembly-line-esque (passed along and viewed in the context of siloed business functions) to becoming much more collaborative. The SBoM is becoming akin to a business intelligence tool, providing the ability for different functions and stakeholders to filter for relevant information.

    Depending on your function, you may be interested in a top-down view of the open source and third-party components across your portfolio of products in order to understand risks in the organization. For instance, as an engineering leader, you may want to understand if you are impacted by a new security vulnerability, where in your portfolio of products you may be exposed and the current status of remediation work for that vulnerability. If you are in legal, you may be interested in a significant licensing change for a component in use at your organization. This allows you to be prepared with changes to legal policies for automated reviews and obligation fulfillment guidance for engineering when the next build occurs and a more recent version of a dependency is pulled in. If you are in the export control function, and are required to provide your application’s encryption capabilities as part of the certification process, understanding which open source components are part of the application, and which provide cryptographic capabilities is essential. Finally, don’t overlook your customers, who today are requiring open source disclosures as part of commercial software contracts to protect themselves from insecure software.

    Collaboration has also been made simpler by the fact that new industry standards now enable an asset portfolio view of open source security. Open Chain obtained ISO certification in late 2020, ISO/IEC 5230:2020, providing a clear and effective process management standard for open source license compliance. It allows companies of all sizes and in all sectors to adopt the key requirements of a quality open source compliance program. Coupled with ISO/IEC 27001–the de facto standard for managing security in information security management systems (ISMS) – organizations can now take a more holistic view of all of their software assets in an effort to make the information they hold more secure.

    Open Source Program Office

    The best way to ensure developers aren’t left footing the bill for open source governance is to create a centralized team dedicated to it. Savvy organizations could form an Open Source Program Office (OSPO), which brings together key stakeholders in legal, engineering, product and security to develop, communicate and operationalize open source strategy for their entire organization. This team works to define a framework and process for consuming open source software as part of their development work (inbound use case) and/or contributing code to the community via open source projects (outbound use case). The mission and main charter of these teams is to help their organization create and manage an open source strategy in terms of the adoption, use, support, participation and development of open source software. However, they’ve also found their role has evolved to become the experts on open source internally and evangelists of the technology and its use.

    The bottom line is that the developer’s job is to develop software – and every piece put in place for stronger open source governance means less time spent focusing on the problems that could be in the open source code and more time on the promise of using it to rapidly innovate for the benefit of their customers.

  • Reducing Friction in Developer Collaboration

    Reducing Friction in Developer Collaboration

    Given how the individual unit of deployment has gotten increasingly smaller, such that the unit of deployment is usually a microservice, it would be tempting to think that individual developers are more able to control how well the code they write (the service they deploy) will work in production. In fact, though, almost the opposite is true. Instead, as the number of services in an environment increases, whether or not one service will work correctly in a production environment has more to do with how well it works with other services rather than the quality of the code.

    This makes collaboration between developers even more critical than ever before, but the packaging of code in microservices actually makes collaboration more challenging. Developers don’t collaborate by working together on a shared codebase — instead they work completely independently on services that could easily be written in different languages, providing the illusion of complete independence.

    In most organizations, ensuring that services work together is a largely informal process. It’s managed by walking over to a colleague’s work station and asking what updates they’re working on or what version libraries they’re using. In a remote work environment, teams rely on Slack messages or Zoom calls to solve issues relating to services interaction. This creates a lot of friction for something that is a critical part of the software development workflow. Failures in service integration can and do cause problems in production.

    Pay Attention to Service Communications

    A perfectly crafted microservice is not going to run in isolation in the production environment. Compatibility issues between each service and upstream and downstream dependencies are just as likely to cause bugs, downtime and poor performance as problems with the code deployed in a container.

    The only way to catch compatibility issues before production is for developers to work together and communicate about the updates they’re working on and how those might impact interdependent services. In the current system, however, this level of collaboration introduces a lot of friction in the development workflow, reducing the individual’s and the team’s velocity. Since developers are generally evaluated based on velocity and code quality — but not necessarily on how well their services work with other services — if the friction remains, developers will be tempted to deploy without fully understanding how dependencies will be impacted.

    Since CI/CD pipelines are generally not set up to test how well services communicate with each other, problems with service fit that aren’t addressed at the development stage generally aren’t found until either a canary deployment goes wrong or there are problems in production.

    Replacing Tribal Knowledge

    One of the other reasons companies need to focus on developer collaboration is that remote work has made it even harder to communicate tribal knowledge. In my experience, no development team has been able to completely wean themselves off of tribal knowledge. Even teams with extensive technical documentation often had or have experienced team members who maintain a unique understanding of the application’s business logic and can share that knowledge when needed.

    Tribal knowledge also relates to service integration and communication — often, insights about how services work together isn’t well-documented, even if each individual service is well-documented. Often, the easiest way to see how they would work together is not to have the two developers responsible for each service work together, but rather to have a senior developer take a look. Especially as development teams work remotely, that type of review isn’t feasible.

    How to Help Developers Collaborate

    Most teams have ways for teams to communicate — they have a Slack setup, they have internal forums and video conferencing solutions. But they often don’t realize that these communication platforms aren’t really collaboration platforms — they are not providing a way for developers to actually work together on interdependent services the way they might if working on a shared codebase. Communication isn’t enough for true collaboration to happen — developers need a way to work together and see how colleagues’ changes impact their own services.

    Facilitating true collaboration, the kind you would get from two people looking at the same screen and coming up with solutions together, is more challenging than making it easier for developers to talk to each other. Without true collaboration, teams will continue to have trouble with communication between services — and there’s no Slack for that.

  • Key Success Factors for Your Nearshore Initiative

    Key Success Factors for Your Nearshore Initiative

    The IT talent shortage is becoming a growing problem. The U.S Bureau of Labor Statistics projects the industry demand for software developers will grow 22% between 2019–2029. This is significantly higher than the average demand growth rate of 4% for all other occupations. As the IT talent gap grows, companies across industries are looking to nearshore partners to help fill the void. Unlike offshoring, nearshoring relies on partners geographically located in the Americas, as opposed to Europe or Asia, for example. It is a growing segment of the market. Case in point, Brazil’s software development services exports have grown 1000% in the last 10 years, gaining an increasing foothold from in the United States for innovative software development and digital transformation initiatives.

    There are several advantages to outsourcing your software development needs to a nearshore partner, including access to high quality IT talent, lower costs, faster time-to-market and, most importantly, the productivity increase that comes with full-time collaboration. With a growing list of global providers in the market, how do you go about selecting the right partner? Here are three important factors to consider.

    Time Zone Proximity

    There are many benefits to being in close geographic proximity and in a similar time zone to your development partner. Being able to have regular iteration reviews during your regular business hours can make or break any project. Everyone is already taxed with a full day of video meetings during the pandemic – why make it more difficult? I’ve heard horror stories from corporate leaders trying to manage partners on the other side of the world with a 12-hour time difference. Time and distance challenges can be disruptive, lower productivity and hurt team building. The importance of real-time communication, feedback and collaboration cannot be underestimated during the software development process. We are all looking forward to getting back to face-to-face meetings, and being in closer geographic proximity will make travel easier once we can gather together again.

    Cultural Alignment

    Teams built on collaborative partnerships are the most successful. The first step to ensuring your teams can successfully tackle your software projects is to make certain the team knows what problems you are trying to solve. That can be more difficult than it seems when working with global partners. My own experience has taught me that different cultures have different work styles and can approach projects in different ways. The culture similarities between North and South America for example, make it easy to stay culturally aligned and approach projects in a more collaborative way. Creativity, innovation and collaboration need to be guiding principles, and your partners should be recognized for their technological capabilities, results and business acumen. Strong teams offer professional support and recommendations during the co-creation process, adding value across all deployment cycles. When projects require collaboration and coordination, cultural alignment becomes more important than ever.

    Ability to Scale

    Most companies start out outsourcing small projects to their partners to gain confidence and trust in the relationship. As that initial project comes to a close, companies often turn to their partners for larger, more complex projects only to find out their partner does not have the right resources to handle that next project.

    As a result, they are forced to restart their search and onboard a new partner. You can avoid this all together by ensuring your nearshore partner can successfully scale their teams and capabilities based on both your current and future needs. Doing your due diligence and verifying a partner’s track record and their ability to rapidly build teams can head off any growing pains. Can they double or triple the team’s size and hire a specific type of developer or engineer? If yes, where are these professionals coming from – in-house or via an outside agency? Does the team have exceptional qualifications and the right skills? How are your partner’s retention rates? It is important to understand how and where the resources will come from when you are ready to expand your relationship. You want companies that are built as nearshoring partners and who are able to scale as you scale.

    Nearshore partnerships are not a one-size-fits-all relationship. To be successful, organizations need to ensure their teams can work cohesively together. The benefits of proximity and time zone overlap, as well as cultural alignment, can ensure the partnership adds value. Collaboration and teamwork will be easier with a team whose culture is similar to yours. Partners who can meet that criteria, and who can demonstrate a similar set of work values, can help you reach your software development and digital transformation goals.

  • Is Low-Code Development a Security Risk?

    Is Low-Code Development a Security Risk?

    According to Gartner, the worldwide low-code development market is projected to be $13.8 billion in 2021, a whopping increase of 22.6% from 2020. Gartner also predicts that the surge in remote development during COVID-19  will continue to boost low-code adoption, despite budget cuts and efforts to optimize cost.

    Low-Code’s Popularity Among Professional and Citizen Developers

    Low-code is no longer the new kid on the block. From simple dashboards to complex applications, low-code applications are becoming more and more diverse, with mainstream adoption in the enterprise world. In essence, low-code is a visual paradigm of application development that involves drag-and-drop of pre-built components and integrations resulting in fast, easy and less-error-prone development.

    The advantage of low-code is that it enables users from a non-traditional development background to participate in the app development process, thus democratizing development and accelerating project timelines. It also narrows the demand-supply gap that arose as organizations catered to ever-rising digitization needs with limited resources and developer scarcity. Many low-code platforms make it easy for citizen developers (business analysts, line-of-business users, junior developers, for instance) to build applications while drastically reducing delivery time compared to traditional coding methods.

    But citizen developer productivity and speed are not the only benefits of low-code development. Today, low-code platforms also come with capabilities purpose-built for professional developers from enterprise IT teams to ISVs. These platforms are hardened for enterprise use, are able to leverage the scalability and security needs of a complex application and have integration capabilities mature enough to seamlessly fit in with existing tools and technologies. During the COVID-19 pandemic, many businesses reinvented themselves through adoption of low-code platforms and applications that helped them adapt to the sudden shift to a remote work scenario and enable the necessary modern application needs that came with it.

    Security Challenges with Low-Code and Remote Work

    Compared to traditional development, low-code involves a variety of personas working together to build applications while dealing with automatically generated code, ready-made components and built-in default configurations. This shift in environment revealed some unique challenges that need to be addressed. There are a few common security challenges with remote teams building on low-code.

    Application Development and Remote Team Collaboration

    • Lack of security awareness: Low-code users come from both business and tech backgrounds. Some practitioners aren’t familiar with application security best practices and lack awareness and understanding of potential vulnerabilities and security holes.
    • Platform access and admin controls: Low-code is deployed centrally and available for users across an enterprise via browser access. This introduces a risk of network intrusion; providing access to unauthorized developers and opening up greater permissions to users that do not need it when accessing the platform remotely.
    • Code repository and team collaboration: Low-code platforms must ensure that the automatically generated code can committed to enterprise-sanctioned repositories. This code access shouldn’t be misused, and ought to have sufficient protocols in place for code control and upgrades.

    Code Generation and DevSecOps Best Practices

    • Securing custom code: Low-code tools allow for writing custom code to extend and enforce platform coding guidelines and design patterns to protect sensitive data from unauthorized access.
    • Adhering to secure release practices: Integration with the existing enterprise CI/CD pipeline is important so that dev teams can extend the same release governance protocol to the auto-generated code before going to production.

    End User Application Access and Data Protection

    • Preventing malicious attacks: Today, both web and mobile apps are becoming constant targets for security breaches. Automatically generated code, and citizen developers working remotely, can make low-code applications more prone to vulnerabilities. Platforms should generate apps that are fully protected against phishing attacks, SQL injections, brute force attacks and DOS attacks.
    • Secure data and application access: Low-code platforms should provide a comprehensive access control mechanism preventing unauthorized access to data and app functionality. With remote teams accessing apps from anywhere, at any time and from any device, data breaches can be prevented with the right controls in place.

    Low-Code and Security – The Future of Development

    As enterprises and ISVs turn to low-code for more serious use cases, the larger question still remains. Can low-code platforms enable modern development teams to deliver applications faster, while still enabling a secure and tightly governed environment?
    The answer is, yes, they can! However, development teams must consider the following security checklist when considering low-code platforms:

    1. The chosen low-code platform must be set up within an enterprise secure DMZ or secure private cloud, and must effortlessly pass cybersecurity clearances.
    2. The platform must enforce best practices in programming (coding conventions, design patterns and data encryption) for automatically generated code as well as custom code written by the developer, facilitating easier integration with existing CI/CD processes and tools.
    3. The platform must offer full protection against the top 10 OWASP vulnerabilities for web and mobile apps, and have third-party certifications to guarantee code quality and security. Also, organizations should ensure that there are no vulnerabilities in their chosen platform’s binaries, as well as all third-party dependencies (including open source libraries) as listed in the CVE library.
    4. The solution must support multiple authentication providers (database, LDAP, AD, SSO, SAML, Open-ID, multifactor, biometric) to build applications with strong user security. For user authorization, ensure support for both coarse-grained as well as fine-grained access control policies to protect various aspects of the application based on RBAC.

    Development teams can embrace low-code technology while ensuring security best practices are in place. Low-code is here to stay, and with the right platform, enterprises and ISVs can make sure security is shifted left and addressed by developers much earlier in the development process. The result is a highly productive, remote workforce churning out applications that are modern, scalable and secure.

  • WhiteSource Acquires Diffend to Secure Open Source Supply Chains

    WhiteSource Acquires Diffend to Secure Open Source Supply Chains

    WhiteSource this week announced it has acquired Diffend as part of an expended effort to discover malware that has been deliberately injected into open source software by a contributor acting in bad faith.

    Company CEO Rami Sass said cybercriminals are increasingly trying to compromise software supply chains that today depend heavily on open source projects. The Diffend platform surfaces anomalous contributor behavior that would be indicative of someone trying to compromise the integrity of a project, said Sass.

    Previously, WhiteSource provided a tool that would discover malware that had been inadvertently included in open source software. WhiteSource now plans to add the Diffend tools, now known as WhiteSource Diffend, for free to a portfolio of security tools that many organizations have already incorporated into DevSecOps workflows. Earlier this month, the company raised an additional $75 million in financing that, in part, was used to fund this acquisition.

    As cybercriminals begin to target software supply chains, many of them are taking aim at open source software that is likely to be adopted by a broad spectrum of organizations, noted Sass. The challenge is that bad actors have become adept at embedding malware in software components in ways that are difficult to detect, he said. However, spikes in activity from, for example, a new contributor to the project might warrant additional investigation, Saas added.

    These type of attacks, unfortunately, will require the maintainers of open source software to vet more closely who is allowed to contribute to the project, added SaaS. New contributors that might have once been greeted with open arms need to now be initially met with a modicum of paranoia, Saas said.

    That level of suspicion will be considerably higher if that contributor is located in a country that has a reputation for trying to compromise the security of both adversaries and companies that have intellectual property they might want to surreptitiously acquire.

    In the wake of some recent high-profile breaches involving software supply chain compromises, organizations are revisiting their application development processes. Cybersecurity teams are now asking developers to vet any external code that is incorporated within an application. Most applications regularly incorporate both open source and commercial components that developers assume have been vetted for malware when, in most cases, they have not. The Diffend platform, for example, aided in the detecting of 60 suspicious packages found in Rubygems, an open source platform that makes it easier to package software built using Ruby programming tools.

    It’s unclear how increased inspection of software components may impact application developer productivity. However, given how dependent organizations are on software today, the discovery of malware downstream that compromises the security of the application is potentially catastrophic.

    Sass said it’s doubtful these security concerns will lead to decreased reliance on open source software in general. There is no real alternative for efficiently driving software innovation, he said. The challenge now is finding a way to make sure all that innovation continues to occur as securely as possible.