devopsy.kinsta.cloud

Category: DevSecOps

Red Hat Moves to Secure Software Supply Chains

Red Hat today announced a portfolio of cloud services designed to better secure software supply chains. The expanded portfolio includes Red Hat Trusted Application Pipeline to secure continuous integration/continuous delivery (CI/CD) workflows and Red Hat Trusted Content offerings to better secure software components.

Announced at the Red Hat Summit, the Red Hat Trusted Software Supply Chain combines a suite of curated open source tools into a cloud service managed by Red Hat. The Red Hat Trusted Application Pipeline service is based on sigstore, an emerging de facto standard for cryptographically signing code to ensure immutability that Red Hat helped drive, while Red Hat Trusted Content provides access to a set of software components that Red Hat has vetted.

Red Hat Trusted Software Supply Chain also provides access to existing tools such as Quay, a registry for containers, and the Advanced Cluster Security (ACS) platform for securing Kubernetes clusters.

Red Hat Trusted Software Supply Chain is scheduled to be made available in preview in the next few weeks, and will also track the provenance of components. In addition, the service will monitor emerging threats to software components and alert users of new and emerging risks. The service will also surface recommendations for remediating vulnerabilities it identifies based on best practices defined by Red Hat.

Finally, Red Hat Trusted Application Pipeline also promises to make it simpler to automate the deployment of secure code with a few clicks within the context of an integrated continuous integration/continuous delivery (CI/CD) pipeline. DevOps team can also import Git repositories and configure container-native continuous build, test and deployment pipelines, inspect source code and transitive dependencies, autogenerate software bill of materials (SBOMs) within builds and verify and promote container images. An enterprise contract policy engine can consistently enforce compliance with the Supply Chain Levels for Software Artifacts (SLSA) framework.

Finding ways to implement DevSecOps workflows is a major challenge for any organization. Red Hat is making a case for a managed cloud service based on a collection of security software and services that a DevOps team would otherwise have to implement themselves.

Tasked with securing increasingly complex software development environments, it’s not clear whether DevOps teams will opt to rely on a cloud service, but given the general lack of security expertise among software development teams, the fastest way to secure a software supply chain for most organizations is to rely on a service.

Regardless of approach, of course, DevSecOps will soon become a standard element of application development workflows. Once that occurs, it’s not clear whether DevOps will simply become DevSecOps or whether security will be assumed to be an integrated element of any set of DevOps best practices.

Sarwar Raza, vice president and general manager for cloud services at Red Hat, said regardless of approach, it’s clear that implicit trust is no longer good enough. Organizations of all sizes will need to be able to demonstrate that they have maintained a chain of custody for the software components used to build an application, he noted.

One way or another, the overall security of downstream applications should eventually improve as the processes used to construct software are increasingly locked down.

May 23, 2023
The Role of SBOMs in Software Supply Chain Security

The software supply chain has become increasingly complex and dynamic with the rise of cloud computing, open source software and third-party software components and APIs. Widespread damage can occur if third-party APIs, cloud services, SDKs and open source software have security flaws. As a result, software supply chain security has emerged as a critical concern for organizations across industries. Supply chain attacks have become more frequent, sophisticated and devastating, as evidenced by high-profile incidents such as SUNBURST, Kaseya and Apache Log4j.

To address the growing challenge of software supply chain security, organizations have turned to leveraging software bills of materials (SBOMs). SBOMs are a standardized inventory of software components used in a particular product or system, including their versions, dependencies and sources. SBOMs provide transparency and visibility into the software supply chain. They can be an effective approach for identifying and mitigating security risks, compliance issues and operational challenges – assuming organizations have the right tools to fully benefit from SBOMs, including runtime discovery, in place.

SBOMs are not a new concept, but their adoption has accelerated in recent years due to a number of important factors, including the following.

First, regulatory agencies, such as the U.S. National Institute of Standards and Technology (NIST) and the Cybersecurity and Infrastructure Security Agency (CISA), have been advocating for SBOMs as a best practice for software supply chain security. NIST has released a draft guidance document on SBOMs, and CISA has mandated SBOMs for federal contractors and subcontractors.

Second, industry initiatives, such as the Open Source Security Foundation (OpenSSF) and the Software Assurance Forum for Excellence in Code (SAFECode), have promoted SBOMs as a key element of software security. OpenSSF has launched a working group on SBOMs and published the Open Source Software Security Mobilization Plan to improve the resiliency and security of open source software (OSS), including guidelines for SBOM management; SAFECode published a whitepaper on SBOMs.

Third, supply chain attacks have highlighted the need for SBOMs as a proactive and preventive measure. SBOMs can help organizations detect and respond to vulnerabilities, malicious code and unauthorized changes in the software supply chain. SBOMs can also support incident response and recovery efforts by providing accurate and comprehensive information about the affected software components.

Fourth, customer demands and market pressures have influenced the adoption of SBOMs. Customers are increasingly aware of software supply chain risks and are asking for SBOMs as part of their procurement and evaluation processes. Some industries, such as health care and automotive, have mandated SBOMs for safety and liability reasons. SBOMs can also enhance brand reputation, customer trust and competitive advantage for software vendors.

Fifth, technological advancements have facilitated the creation and consumption of SBOMs. The emergence of open standards, such as CycloneDX and SPDX, has enabled interoperability and integration of SBOMs across different tools and platforms. The development of automated tools, such as software composition analysis (SCA) and vulnerability scanners, has enabled the generation and validation of SBOMs in a timely and accurate manner. The integration of SBOMs with other security measures, such as identity and access management (IAM) and security information and event management (SIEM), has enabled an effective view of software supply chain security.

However, SBOMs are not a silver bullet for software supply chain security. They are only as good as the data they contain, and the quality of data can vary depending on the source and the method of collection, particularly around the application software stack of APIs, cloud services and SDKs. SBOM inventory is constantly changing, and being able to leverage their up-to-date data requires more than a snapshot from traditional source code static analysis approaches, but rather continuous runtime analysis and dynamic inventory.

For example, common vendor management and software composition analysis (SCA) approaches often lack source code access for mobile, web, cloud and commercial-off-the-shelf (COTS) software, as well as third-party API services.

For a more effective approach, organizations can benefit from a full-stack attack surface management (ASM) software supply chain solution that delivers continuous third-party application asset discovery and dynamic tracking of third-party vendors. These newer approaches automatically categorize assets under known vendors, allow customers to add additional new vendors, curate individual assets under any vendor, and alert on increases in policy violations and high embed rates of third-party vendors within key applications. These automated capabilities allow vendor management teams to remedy supply chain security problems more quickly and easily and much more accurately than older approaches.

It is important to note that SBOMs also require collaboration and communication among multiple stakeholders, including software vendors, suppliers, customers and regulators. They may also pose some privacy and intellectual property concerns since they can reveal information about the software components and their relationships.

Overall, organizations need to adopt a comprehensive and risk-based approach to software supply chain security, of which SBOMs and tools to best leverage their information are an important component. Organizations should establish policies and procedures for SBOM creation, management and sharing, as well as for validation and verification. Organizations should also integrate SBOMs with other security measures and practices, such as threat modeling, penetration testing and code review to best ensure the security of their software supply chains.

May 23, 2023
Five Great DevOps Job Opportunities

devopsy.kinsta.cloud is now providing a weekly DevOps jobs report through which opportunities for DevOps professionals will be highlighted to better serve our audience.

Our goal in these challenging economic times is to make it easier for DevOps professionals to advance their careers.

Of course, the pool of available DevOps talent is still relatively constrained, so when one DevOps professional takes on a new role it tends to create an opportunity for others.

The five job postings shared this week are selected based on the company looking to hire, the vertical industry segment and, naturally, the pay scale being offered.

We’re also committed to providing additional insights into the state of the DevOps job market. In the meantime, for your consideration:

LinkedIn

Samsung Electronics America
Mountain View, California
Lead Site Reliability Engineer (SRE) – DevOps Specialist
$180,000 to $210,000

Indeed.com

Federal Reserve Bank of New York
New York, New York
DevOps Engineer
$178,100 to $207,900

CareerBuilder.com

SAIC
Chantilly, Virginia
DevOps Advisor
$130,000 to $200,000

Dice.com

Saicon Consultants
Alpharetta, Georgia
DevOps Engineer
$110,000 to $140,000

Simply Hired.com

Hewlett-Packard Enterprise
Fort Collins, Colorado
DevOps Automation Engineer
$109,400 – $251,500

May 22, 2023
How Test-Driven Methodologies Reduce CI/CD Lead Time
Modern development environments, in which rapid continuous delivery is facilitated by automated continuous integration/continuous development (CI/CD) pipelines, require thorough and automated testing in development prior to integration. This article explains how test-driven development (TDD) and acceptance test-driven development (ATDD) methodologies reduce CI/CD lead times.

Lack of test automation in development impacts CI/CD lead time for subsequent integration, delivery and deployment stages of a CI/CD pipeline in the following ways:
- Increased defect rate: Without automated testing during the development stage, more defects and issues are likely to be introduced into the codebase, increasing the time spent on debugging and fixing issues in later stages.
- Slower feedback loop: Without test automation, the feedback loop between code changes and test results is slower, making it more challenging to identify and resolve issues quickly. This delay can impact the overall lead time in the CI/CD pipeline.
- Reduced confidence in releases: When testing is not performed adequately or isn’t automated, there is less confidence in the quality of the software being released. This may lead to more manual testing and validation, further increasing lead times.
- Inefficient use of resources: Without test automation, developers and testers need to spend more time on manual testing, reducing the time available for developing new features or fixing existing issues.
- Increased merge conflicts: When test automation is not performed early in the development stage, the risk of merge conflicts increases as different developers work on the same codebase. Resolving merge conflicts can be time-consuming and may cause delays in the integration, delivery, and deployment stages.
- Decreased stability and reliability: Inadequate test automation during the development stage can lead to less stable and reliable software. This may require additional time and effort to address issues and ensure that the software is production-ready.
- Inconsistent test environments: Manual testing may not always be conducted in a consistent environment, leading to potential discrepancies between development, staging, and production environments. This can cause unexpected issues and delays in the pipeline.
- Hindered collaboration: Lack of test automation may reduce visibility into the quality of the codebase, making it more difficult for team members from development, QA, security and operations to collaborate effectively and identify issues early.
Although CI/CD pipelines help catch issues and ensure code quality through automated builds and tests, having a strong foundation of test automation during the development stage helps minimize the potential for issues in the pipeline and ensures a smoother CI/CD process.

There are several reasons why many development teams do not automate tests prior to integration, despite the benefits of doing so.
- Lack of awareness or understanding: Some development teams may not be aware of the benefits of test automation or may not fully understand how to implement it effectively in their development process.
- Insufficient skills or experience: Test automation often requires specialized skills and knowledge, and some development teams may lack the necessary expertise to implement it effectively.
- Time constraints: Developing and maintaining automated tests can be time-consuming. Teams working under tight deadlines might prioritize feature development over creating automated tests, believing that it will save time in the short term.
- Limited resources: Test automation tools and infrastructure can require significant investments in terms of cost and resources. Some organizations may not have the necessary budget or resources to invest in test automation, especially for smaller projects or teams.
- Resistance to change: Some teams may be resistant to adopting new practices, particularly if they have been successful with their existing processes. Changing established workflows and learning new tools can be challenging and may encounter resistance from team members.
- Incomplete or rapidly changing requirements: In situations where requirements are unclear or frequently changing, development teams may struggle to create meaningful automated tests, as they may require continuous updates to stay relevant.
- Overemphasis on manual testing: Some teams may place a greater emphasis on manual testing due to a belief that it provides more accurate or thorough results. This perception can lead to a reluctance to invest time and effort into developing automated tests.
- Fear of increased maintenance: Automated tests, like any other code, need maintenance and updates as the application evolves. Some teams may be concerned about the additional effort required to maintain a test suite, particularly if they have limited resources.
The amount of test automation that should be done in development prior to the integration stage of a CI/CD pipeline depends on several factors, including the complexity of the application, team resources and the specific project requirements. However, here are some general guidelines to help you determine the right balance:
- Unit tests: Developers should aim to automate most, if not all, unit tests during the development stage. They are typically fast to execute and provide quick feedback, allowing developers to catch issues early and minimize the number of defects that make it to the integration stage.
- Component and integration tests: While unit tests focus on individual components, component and integration tests verify the interaction between different components or services. These tests should be automated as much as possible to ensure that any issues arising from component interactions are identified and resolved quickly.
- Static code analysis: Automating static code analysis checks during development helps identify code quality issues, security vulnerabilities, and potential performance bottlenecks early in the process.
- Code coverage: Strive for a high level of code coverage with your automated tests. However, it’s important to remember that code coverage is just one indicator of test quality and should be complemented by other testing strategies.
Striking the right balance between automated and manual testing is important. Automate tests that are repetitive, time-consuming or prone to human error. Manual testing should be reserved for exploratory testing, usability testing and other areas where human intuition and judgment are necessary.

Test-driven development (TDD) and acceptance test-driven development (ATDD) are development methodologies that emphasize creating automated tests before writing the actual code, helping teams ensure code quality and catch issues early prior to integration.

Test-driven development (TDD) is a software development methodology that emphasizes writing tests before writing the actual code. The primary goal of TDD is to create clean, maintainable and bug-free code by catching issues early in the development process. TDD follows a short iterative cycle consisting of three main steps: Write a test, make the test pass and refactor the code. The developer starts by writing a test for a specific feature or function, which initially fails. Next, the developer writes the minimal amount of code necessary to make the test pass. Finally, the developer refactors the code to improve its structure and readability while ensuring that all tests still pass.

Acceptance test-driven development (ATDD) is an extension of TDD that focuses on defining and validating the high-level requirements and acceptance criteria for a feature or functionality before development begins. ATDD involves collaboration among developers, testers, and business stakeholders to ensure that the application meets the needs of its users. The process begins with writing acceptance tests, which are derived from the user’s perspective and based on the acceptance criteria. These tests are written in a human-readable language to facilitate clear communication among all team members.

Once the acceptance tests are defined, the development team follows the TDD process to implement the feature, using the acceptance tests as a guide. As the team develops the code, they also create unit tests and other lower-level tests to validate the implementation. The acceptance tests are executed as part of the development process and serve as a measure of progress. When all acceptance tests pass, it indicates that the feature or functionality meets the defined acceptance criteria, and the development task is considered complete. By using ATDD, teams can improve collaboration, ensure that the application meets user expectations and reduce the risk of miscommunication or misunderstanding requirements.

Hurdles to overcome when transitioning to TDD and ATDD include:
- Mindset shift: Adopting TDD and ATDD requires a change in mindset, where testing is considered an integral part of the development process rather than an afterthought.
- Skill development: TDD and ATDD require specialized skills in writing effective tests and implementing test automation. Development teams may need to invest time and resources in acquiring these skills.
- Time and resource allocation: Transitioning to TDD and ATDD might initially lead to a perceived increase in development time, as writing tests before code can seem slower. However, the long-term benefits of improved code quality and reduced debugging time should be considered.
- Collaboration and communication: ATDD relies on effective collaboration and communication among developers, testers, security, operations and business stakeholders. Establishing a culture of open communication and collaboration is crucial.
- Tooling and infrastructure: Implementing TDD and ATDD may require investments in new tools or changes to the existing development infrastructure to support test automation and continuous integration.
In the context of TDD and ATDD, the roles of quality assurance (QA), security and operations teams are crucial for ensuring a well-rounded and robust software development process. Their involvement helps to address various aspects of the application, leading to a more reliable and secure product.
- Quality Assurance (QA): QA team members collaborate closely with developers in both TDD and ATDD methodologies. They can help define test cases, create test plans and provide input on acceptance criteria. In ATDD, they play a particularly significant role in developing and validating acceptance tests, ensuring that the application meets the defined requirements and user expectations. QA team members may also be involved in setting up and maintaining test automation infrastructure, analyzing test results and identifying areas for improvement.
- Security: Security professionals contribute to TDD and ATDD by identifying potential security vulnerabilities and ensuring that the application is developed with security best practices in mind. They can help define security-related test cases and help to embed security into the application, reducing the risk of vulnerabilities and improving the overall security posture.
- Operations: Operations teams are responsible for managing the infrastructure and deployment processes that support the application. In TDD and ATDD, they can collaborate with developers to ensure that the application is designed and developed with operational concerns in mind, such as scalability, performance and maintainability. Their involvement also helps to promote a DevOps culture where development and operations teams work together to ensure the application’s success in production environments.
A practical roadmap for teams to transition to TDD and ATDD while overcoming the hurdles mentioned earlier could look like this:

Build awareness and buy-in:
Provide training and skill development:
Start small and iterate:
Foster a culture of collaboration:
Set up the necessary tooling and infrastructure:
Monitor progress with metrics:
Continuously improve and adapt:
Summary

TDD and ATDD methodologies contribute to reducing CI/CD lead times by automating tests during development. This improves code quality, minimizes defects and promotes collaboration among team members from the outset of the development process. By writing tests before the actual code and focusing on meeting acceptance criteria, teams can catch and resolve issues early, leading to fewer delays and reduced time spent on debugging and fixing errors during the integration, delivery and deployment stages. These practices also help ensure that the application aligns with user expectations and operational requirements, resulting in a smoother and more efficient CI/CD pipeline.

Anyone who is passionate about modern quality engineering processes for building high-quality software to participate is encouraged to join new ShiftSync Community from Tricentis to engage in discussions about this topic and other development methodologies.
May 19, 2023
Despite DevOps, Software Supply Chain Security Challenges Persist

A survey of 397 IT, cybersecurity and application development professionals conducted by Enterprise Strategy Group (ESG) found that while most respondents work for organizations that have adopted DevOps practices, multiple software supply chain security issues and DevSecOps concerns have yet to be addressed.

The survey, conducted on behalf of Data Theorem, a provider of a platform for securing application programming interfaces (APIs), the survey also found 82% of respondents have adopted DevOps, with 51% reporting they make extensive use of DevOps workflows (51%). Nearly three-quarters (73%) are deploying code weekly and 31% are deploying code daily.

However, securing DevOps workflows remains a work in progress, with 41% reporting security teams lack visibility and control of development processes. Other issues include new builds deployed to production with misconfigurations, vulnerabilities and other security issues (40%), developers skipping security processes (39%), software released without going through security checks and/or testing (38%), lack of security process consistency across different development teams (38%), security team can’t keep pace with release cadences (34%) and developers’ reluctance to work with security (29%).

API security is also becoming especially challenging, with 92% of respondents dealing with at least one API security incident in the last 12 months. Well over half (57%) have dealt with multiple API security issues in the last 12 months.

On the plus side, the survey also found that more than half (54%) of teams responsible for securing APIs are involved with development as soon as or before the APIs are published. A full 97% said developers either have a good (22%) or high level (71%) of API security knowledge. A total of 89% reported their organization provides formal API security training to their development teams. More than three-quarters (78%) can remediate an API vulnerability within a day, and 39% reported they can do so within hours. A total of 60% reported a dedicated budget has been specifically allocated to API security, with another 30% identifying it as a discrete item within their cybersecurity budget. Two-thirds (66%) said spending on API security would significantly increase in the next 12 to 18 months.

The use of APIs is only going to increase in the months and years ahead. Well over one-third (36%) of respondents are using APIs across all their applications, with 50% expecting this to be the case in two years. Another 44% reported most of their applications are using APIs., with 32% expecting this to be the case in two years. More than three-quarters (76%) of organizations reported that they have an average of 26 APIs per application and 53% have more than a quarter of their APIs facing the internet.

More than a third (35%) are updating APIs daily while another 40% do so weekly. A full 61% are using APIs to connect microservices.

Data Theorem COO Doug Dooley said those APIs are now being targeted by cybercriminals that routinely test the weaknesses of every API after each deployment and update. The most common types of API attacks reported by survey respondents included exposure of data (32%), account takeover (31%), denial of service (DoS) attack (31%), attack on misconfigured API (30%), fake account creation (28%), API injection attack (28%), ransomware (27%), data breach (26%) and content scraping (26%).

Despite these issues, however, nearly three-quarters (74%) of survey respondents said they believe their organizations have a robust API security program in place, with 22% reporting they have some process in place. Organizations are using a mix of approaches including API security tools (59%), web application firewalls (WAFs) (57%) and API gateways (50%), distributed DoS mitigation (48%) and bot management solutions (42%).

Challenges included managing multiple tools (29%), visibility into and control of APIs (28%), inventorying APIs (27%), inconsistent adoption of APIs (27%), API security testing (27%), data governance/exposure (26%), discovering and remediating misconfigured APIs (26%), keeping pace with threats (26%) and accurately tracking API usage (25%).

Significant API security concerns included API authentication issues (41%), account takeovers (39%), identifying and tracking third-party APIs (38%), using tools not purpose-built for security (38%), shadow/undiscovered APIs (38%), abusive behavior bypassing app security tools (38%), denial of service attacks (38%), data governance and/or data exposure issues as a result of insecure APIs (37%), abusive behavior bypassing bot management (37%) and outdated/unneeded APIs, also known as zombie APIs. (33%).

The type of vulnerabilities that are of the greatest concern are sensitive data exposure (34%), access control vulnerabilities (31%), API business logic flaws (31%) and DDoS attacks (30%).

More than 79% of respondents, however, are relying on manual testing and review processes to ensure APIs don’t expose sensitive data (79%), with 63% having automated alerting capability for when sensitive data is exposed.

Overall, it’s apparent that more resources as being applied to securing software supply chains in general and APIs specifically. However, given the amount of software being built and deployed, it may be a while before organizations see the return on those investments.

May 18, 2023
ServiceNow Adds Observability Platform to SaaS Portfolio

At its Knowledge 2023 conference, ServiceNow launched an observability service that runs on its software-as-a-service (SaaS) platform.

Based on the observability platform the company gained with its acquisition of Lightstep, the ServiceNow Cloud Observability platform makes it possible to collect and analyze data collected from software running on infrastructure and also from workflows created using ServiceNow applications.

Pablo Stern, senior vice president and general manager for technology workflows products at ServiceNow, said the goal is to make it simpler to investigate IT issues involving applications and workflows that have multiple dependencies. That makes it possible to quickly diagnose an issue, determine the root cause and then dispatch the right site reliability engineering (SRE) team to troubleshoot it, he added.

ServiceNow Cloud Observability uses both open source OpenTelemety agent software to collect logs, metrics and traces in addition to a log management tool that ServiceNow gained last year with its acquisition of Era Software.

In addition, ServiceNow is employing a Service Graph Connector that makes it simpler to pull data from, for example, OpenTelemetry and Kubernetes clusters into the ServiceNow IT Operations Management (ITOM) without requiring any additional tooling. ServiceNow is also making available its Unified Query Language to make it possible for IT teams to query the data residing in ServiceNow Cloud Observability.

As application environments become more complex, the need for entire IT teams to have access to an observability platform is growing. While observability has always been a core tenet of DevOps best practices, Stern said it’s clear that these capabilities also need to be made available to IT administrators. In fact, as observability becomes more democratized, it will drive the rise of services operations that will enable IT teams to be better aligned around specific processes, he added.

Most IT organizations today employ a wide range of tools that enable them to monitor a set of pre-defined metrics. Observability platforms, in contrast, enable IT teams to collect data from systems in a way that can be investigated using a query tool.

It’s still early days as far as the adoption of observability platforms is concerned, but as the collection of logs, metrics and traces becomes more unified, an opportunity to better converge IT practices based on DevOps principles and the ITIL framework that many IT administrators rely on to manage IT will emerge.

The challenge, regardless of what methodology is used, is that IT teams need to be able to frame the queries they use to discover the root cause of an IT issue before any potential disruption occurs. In the long term, however, it’s expected that machine learning algorithms will leverage the data collected by observability platforms to automatically identify those issues.

Regardless of how an IT issue arises, the metric that matters most is how quickly it can be resolved—no matter who in the IT team is tasked with resolving it. The issue is finding a way to provide IT teams with better tools to achieve that goal.

May 17, 2023
DevOps Security: Your Complete Checklist

In a fast-paced environment like DevOps, your security strategy needs to be even more agile. While moving fast is great for delivering application features and functionality, speed shouldn’t come at the cost of security.

DevOps security incorporates security strategies directly into your DevOps pipeline, creating a culture of pre-secured software deployments that work seamlessly for the end user. However, this requires a complete shift in your operational policies and security mindset. You need to start viewing security as an integral part of your DevOps lifecycle instead of a separate department.

Here’s a checklist of DevOps security strategies for your development teams to deliver secure and reliable applications faster:

Your Complete DevOps Security Checklist

1. Analyze your development process for security hazards.
The first step in implementing a DevOps security strategy is finding and fixing loopholes in your existing development process.

For instance, continuous delivery and development are key in a DevOps environment. However, if each change doesn’t go through a code review, it has the potential to break your application.

Deploying changes without passing them through a security checkpoint is like driving at high speed on a road with many curves. Each curve (change) is a potential hazard, and the danger increases when the driver does not know a car is coming from the other side (bug).

Therefore, you must turn the spotlight on your development process and find those curves.

2. Create a common goal between development and security teams.
Traditional roles of developers and security teams might look like they are at crossroads — Developers write code, and security teams find fault with their code. However, in a collaborative environment such as DevOps, security and development must work hand-in-hand to deliver a secure and seamless experience to end users.

Your organization should have a common goal of integrating security directly into the development process. Therefore, encourage open and regular communication between development and security teams. Further, establish joint milestones and review them to ensure there are no silos between both teams.

Once these teams get used to this collaborative approach, your deployments will become faster because fewer things will break.

3. Integrate security procedures in the development phase.
Automation is the lifeblood of DevOps security. Integrating scanning tools into development workflows is critical to your entire process.

For example, automated tools can scan the code, network and infrastructure to identify security vulnerabilities and provide recommendations for remediation. With this, development teams can fix a few security concerns themselves before passing them on to the security team for a final check.

4. Add observability to your pipeline.
One of the biggest challenges of the distributed nature of DevOps operations is visibility. How do you efficiently monitor a large number of operation nodes spread across several different locations?

Observability helps you do this by using logs, metrics and traces—i.e., the outputs of your application to determine internal application health. With observability tools, you can see much deeper into the operations of your systems and identify the exact details of any security concerns. You can also easily identify potential bugs and fix them before they cause problems.

5. Make changes in small, incremental units.
It is infinitely easier to test code in small units and deploy them as minor but incremental changes than handling large, unwieldy blocks of monolithic code. Deploying gradual changes means you can resolve vulnerabilities faster.

6. Scan and secure your entire DevOps pipeline.
A large part of the security hazards in your DevOps process comes from unsecured containers and operations nodes. According to a study from ThreatStack, 94% of organizations say containers represent a security risk.

However, the risk is not limited to containers.

Other services like APIs, third-party tools like Docker and imported code pose a potential security risk to your processes. This makes it necessary to scan all your operations nodes periodically for vulnerabilities. And once you’ve cleared them, remember to lock the door behind you by requiring strict credentials for access to your administrative dashboards.

Ticking Items Off Your DevOps Security Checklist

If you implement most of the security guidelines on this checklist, your organization will have a solid security foundation. However, DevOps security is not a one-time process.

You will need to continuously integrate security protocols into each part of your DevOps life cycle. Furthermore, you will need to re-train your employees and invest in new technology that makes your security pipeline smoother, such as observability.

However, since this entire process makes your applications more secure and compliant while shipping them to market faster, investing in DevOps security is well worth it!

May 17, 2023
AWS Converts Cedar Policy-as-Code Tool to Open Source Project

At the Open Source Summit North America conference today, Amazon Web Services (AWS) announced it is making Cedar, a language for defining permissions as policies that includes automated reasoning to mathematically prove an IT environment is secure, available as an open source project.

In addition, AWS launched SnapChange, an open source fuzz testing tool that cybersecurity researchers can employ to discover vulnerabilities by replaying physical memory snapshots in a KVM virtual machine. Fuzz testing uncovers software security issues by monitoring how the system behaves while processing random data.

David Nalley, director of open source marketing for AWS, said both projects are part of an ongoing AWS effort to contribute intellectual property to the open source community that plays a pivotal role in the applications that organizations deploy on the AWS cloud.

AWS has been employing Cedar to provide IT organizations with the ability to write authorization policies as code that can be deployed anywhere. It is most widely used within the managed AWS Verified Permissions service that manages those processes on behalf of organizations that deploy workloads on its cloud.

Cedar differs from other policy-as-code approaches because it employs automated reasoning, a computer science discipline that is considered a subset of artificial intelligence (AI), to enable machines to prove theorems and checks. That latter capability is especially critical to enable organizations to mathematically prove that compliance mandates have been continuously met, noted Nalley.

Otherwise, IT organizations become wholly dependent on an assessment of intermittent audits conducted by humans that are likely to arrive at varying subjective conclusions, he noted.

The latest open source contributions from AWS come at a time when there is more scrutiny being applied to how open source software is developed and employed. The scrutiny increased in the wake of a series of vulnerability disclosures involving open source software, such as the Log4j monitoring software project.

The maintainers of many open source software projects often don’t have the resources or capabilities required to immediately patch a vulnerability every time it is discovered. That’s become especially problematic, because more research into open source software vulnerabilities is being conducted; it’s only a matter of time before a vulnerability is detected in software that was largely created by developers that have limited cybersecurity expertise. Enterprises that consume open source software need to pay careful attention to what dependencies they are creating when that software gets incorporated into an application environment. A patch for a zero-day vulnerability that is discovered might not be readily available.

Hopefully, consumers of open source software will become more involved in its development by contributing code or making available the financial resources that maintainers need to devote time and effort to creating a timely patch to a vulnerability. In the meantime, however, they should also be reviewing what open source software is included in applications running in production environments. Cybercriminals are increasingly looking to discover and exploit vulnerabilities in not just existing applications but not also in components they know are likely to be employed across a wide range of downstream applications.

As such, finding ways to apply more cybersecurity expertise to application development by embracing DevSecOps practices has become an imperative rather than a recommendation.

May 10, 2023
GitGuardian Survey Surfaces Secrets Management Challenges

A survey of 507 IT decision-makers in the U.S. and the United Kingdom published today found 75% of respondents said a secret leaked from at least one application, with 60% noting that the leak caused issues for either the company, employees or both.

Conducted by Sapio Research on behalf of GitGuardian, a provider of a platform for securing application secrets, the survey found less than half of respondents (48%) are confident in their ability to protect application secrets to a great extent.

The top source of risks when it comes to secrets management are source code and repositories (58%), followed by hard-coded secrets (47%). Just under a third (30%) of respondents to the GitGuardian survey admitted they share passwords and secrets when building applications as clear text within a messaging application.

Just over a quarter (27%) still relied on manual code reviews to prevent secrets leaks, the GitGuardian survey found.

On the plus side, 94% of the respondents said they were considering improving their secrets management practices in the coming 12-18 months, even though 93% said either “all” or “some” of their repositories were continuously scanned for hard-coded secrets.

Thomas Segura, a cybersecurity expert for GitGuardian, said as the number of applications developed continues to increase, secrets sprawl has become a bigger challenge for application security. The way secrets are managed during application development has become a bigger issue in the wake of a series of software supply chain breaches that led to malware being injected into applications.

The concern is cybercriminals that compromise software development environments will be able to retrieve secrets that they can later use to compromise an application after it has been deployed in a production environment. Cybercriminals are also now routinely scanning for secrets that may have been stored in text after an application has been deployed.

The challenge is that secrets have not been historically managed effectively, so many organizations are now looking to implement more rigorous processes. Another challenge is that, in many cases, it’s not apparent whether those processes will be implemented by a DevOps team familiar with how an application is constructed or an application security team with more cybersecurity expertise, noted Segura.

Regardless of the approach to remediating these issues, there is always going to be an issue because the humans who build applications are always going to make mistakes. The goal is to minimize the number of secrets that might be leaked by implementing DevSecOps practices that automate the review process, said Segura.

In theory, at least, advances in artificial intelligence (AI) should make it easier to automate more of the secrets review process. In the meantime, however, organizations need to review their existing processes in advance of pending legislation that looks to hold organizations more accountable for application security if it is determined that the organization did not take reasonable precautions.

It may be a while before such legislation becomes law, but one way or another, it’s clear that DevOps teams are soon going to be asked tougher questions about how secrets were managed every time an application security breach occurs.

May 9, 2023
ReversingLabs: Increased Focus on Software Supply Chain Security

A global survey of 300 global executives, technology and security professionals found software containing vulnerabilities (82%) followed by secrets leaked through source code (55%), malicious code (52%) and suspicious code (46%) posed a serious risk to the business.

Conducted by Dimensional Research on behalf of ReversingLabs, a provider of a platform for securing software supply chains, the survey found 87% of respondents detected significant risks in their software supply chain in the last year. Nearly three-quarters (74%) said legacy application security tools, including static application security testing (SAST) (54%), dynamic application security testing (DAST) (42%) and software composition analysis (SCA) (40%), are ineffective against threats to modern software supply chains.

A full 88% said software supply chain security is an enterprise-wide risk, but only 60% said their software supply chain defenses were up to the task. Nearly two-thirds (65%), however, acknowledged their organization’s software supply chain security program wasn’t as mature as it should be. As a result, 80% are currently focused on improving security for the software supply chain, with 96% noting a more comprehensive approach to software supply chain security that detects more than vulnerabilities is needed.

Overall, the survey found nearly all respondents (98%) recognized that software supply chain issues pose a significant business risk. Nearly 90% reported detecting security or other issues in their software supply chain in the last 12 months. Those issues stemmed from internally developed software (47%) as much as open source software (49%), followed by commercial software (30%), the survey finds.

Tyson Whitten, vice president of global marketing for ReversingLabs, said the survey results make it clear that software supply chain issues extend well beyond open source software dependencies. Use of open source software has expanded greatly over the last decade, but security flaws in software are pervasive, he noted.

In addition, many of these issues stemmed from software created by contractors and third-party companies, added Whitten. More than half of respondents worked for organizations that use contractors (67%) and third-party development companies (59%) and many organizations don’t have the tools required to review applications before they are deployed in a production environment.

Software supply chain security has become a major issue in the wake of a series of high-profile breaches. The challenge is shortage of cybersecurity expertise available to secure those supply chains. Usually, someone on the DevOps team needs to emerge as a security champion for the good of the larger application development team. Unfortunately, most developers have had limited exposure to cybersecurity training, so it can take a significant amount of time for those champions to emerge.

In the meantime, it’s less clear whether organizations will upgrade their DevOps environments to make them more secure, but it’s clear they will soon be held more accountable for application security. Governments around the world are currently drafting legislation that would impose penalties should it be determined an organization recklessly built and deployed software. Once that legislation is passed, it may only be a matter of time before the pressure on organizations to adopt DevSecOps workflows increases. The issue is determining how quickly to get in front of that issue before a potential legal quagmire ensues.

May 5, 2023