TAKE NOTE (Insights and Emerging Technology)
In a move that has reverberated across the federal contracting landscape, the U.S. Small Business Administration recently suspended more than 1,000 firms participating in its flagship 8(a) Business Development Program for failing to submit required financial data by a January deadline. The suspensions, part of a sweeping compliance push tied to a broader audit of the program, underscore rising expectations for transparency and regulatory adherence among small businesses seeking set-aside and sole-source contract opportunities.
The data request, issued to all roughly 4,300 active 8(a) participants last December, sought a comprehensive set of financial documents, including bank statements, payroll records, contract information, and general ledgers from the past three fiscal years. Firms that missed the January 19 cutoff — or submitted incomplete responses — were deemed non-compliant and subsequently suspended. The SBA has given affected companies 45 days to appeal their suspensions through its Office of Hearings and Appeals.
For many in the small business community, the scale of the action — roughly a quarter of the entire 8(a) cohort — has stoked concern about administrative burden and the potential chilling effect on participation. Some firms reported technical issues with the submission portal and timing challenges that may have contributed to missed deadlines. At the same time, SBA officials have emphasized the importance of rigorous oversight as part of efforts to root out fraud, abuse, and pass-through entities that may exploit the program’s benefits.
As firms navigate the appeal process and adjust to heightened reporting requirements, contractors and advisors alike are watching closely for further guidance from SBA on reinstatement criteria and future compliance deadlines. The implications of this enforcement action will likely shape small business contracting strategies well into 2026
Read more at Federal News link below
Interested in learning more about RPA? Download our FREE White Paper on “Embracing the Future of Work”
UNDER DEVELOPMENT (Insights for Developers)
Rethinking DevSecOps in Government Systems
Intro
For most of the last decade, DevSecOps has been framed around a single organizing principle: shift security left. Move controls earlier in the lifecycle, automate scanning, and catch issues before they reach production. The logic was straightforward. Earlier detection should reduce cost, improve quality, and accelerate delivery.
In Government regulated environments, however, that promise rarely materialized.
By 2026, many federal programs have reached a more sober conclusion. Simply moving security earlier does not make it more effective. In some cases, it made delivery harder without measurably reducing risk. As a result, DevSecOps is evolving again. The industry is moving away from a rigid interpretation of shift left and toward a more disciplined approach that many teams now describe as shift smart.
This shift is not about weakening security. It is about aligning security controls with mission context, operational risk, and how systems are actually delivered. Nowhere is this more important than in federal environments running large enterprise platforms such as SAP, where security, compliance, and mission execution are tightly coupled.
Why Shift Left Stalled in Federal Programs
Early DevSecOps adoption in federal programs often followed a predictable pattern. Security tools were added to CI/CD pipelines to demonstrate early and continuous coverage. Static code analysis ran on every commit. Dependency scans flagged any vulnerable library. Configuration checks enforced broad policy rules across all environments.
What was missing was judgment.
For example, teams routinely blocked builds because a static analysis tool flagged a low-likelihood coding issue in a batch process that only ran inside a controlled enclave. That same pipeline applied identical gating rules to an internet-facing API supporting real-time operations. From the tool’s perspective, both findings were “critical.” From an operational perspective, they were not even close
The result was developer fatigue, security workarounds, and a growing disconnect between compliance artifacts and real risk. Programs spent time addressing findings that looked serious on paper while exploitable issues competed for attention in the same backlog. Shift left did not fail because it was wrong in principle. It failed because it treated all risk as equal.
What “Shift Smart” Looks Like in Practice
Shift smart DevSecOps starts with a different question. Instead of asking whether a control exists or whether a scan ran early enough, teams ask whether a control meaningfully reduces risk for this system, in this environment, at this point in time.
In practice, this often shows up as pipelines that behave differently based on context. A code change that modifies authentication logic in a production-facing service triggers strict automated gating, security review, and evidence capture for ATO traceability. A change that updates a reporting job in a development environment may still be scanned, but the findings are logged and tracked rather than blocking delivery.
The same tooling is used in both cases. The difference is policy, not technology.
In SAP environments, this distinction matters even more. A transport that updates a core financial posting routine deserves different scrutiny than one that modifies a report layout or workflow configuration. Shift smart pipelines recognize that difference automatically, instead of forcing security teams to adjudicate it manually at the end of the process.
– Dig Deeper –
Understanding the Sec in DevSecOps: Beyond Just Shifting Left
Q&A (Post your questions and get the answers you need)
Q. How do you secure SAP customization without over-customizing the SAP S/4HANA environment?
A. The best way to secure SAP customization is by deliberately limiting where customization is allowed and by treating customization decisions as security and lifecycle decisions rather than purely technical ones.
The approach is based on an ERP-first, extension-second model that preserves the integrity of the SAP S/4HANA core while still allowing the organizations to meet mission, business, and integration requirements. By keeping the core as close to standard as possible, we reduce attack surface, simplify compliance, and ensure that the system remains upgradeable over time.
We prioritize fit-to-standard configuration and treat standard SAP functionality as the default secure baseline. Configuration is preferred over custom logic because it is fully understood by SAP, consistently supported across releases, and already aligned to SAP’s internal security and control frameworks. Standard business processes, data models, and authorization concepts are used wherever possible, and SAP-delivered roles and security constructs are leveraged as the foundation for access control. Any deviation from standard behavior is evaluated not only for functional necessity, but also for its impact on security posture, audit scope, and long-term sustainment.
However, there will be times when requirements cannot be satisfied through standard configuration alone. When this happens, we avoid modifying the core ERP and instead extend the platform in controlled and well-governed ways. Mission-specific logic, user experience enhancements, and integration workflows are implemented outside the S/4HANA core using SAP Business Technology Platform, SAP Fiori and UI5 applications, and published APIs and event mechanisms. This approach allows innovation and differentiation without weakening the system of record. Extensions operate within clearly defined security boundaries, which means that changes, failures, or security incidents in an extension can be isolated without compromising core financial, logistics, or personnel data. ( see infographic below)
By keeping the S/4HANA core clean and stable while placing controlled flexibility at the edges, we reduce operational risk and improve system resilience. This approach simplifies upgrades, strengthens security, and supports mission agility without recreating legacy ERP problems in a modern platform. Ultimately, securing SAP without over-customizing is about reducing the blast radius of change and ensuring that the system remains trustworthy, auditable, and sustainable over its full lifecycle.
Cheers!