In Folsom the asset that matters is the design itself - the RTL, netlists and GDSII layouts that represent years of R&D - and the sharpest risk is that data leaving the building. CyberFortify runs manual design and source-code review, cloud, network and API penetration tests here, focused on design-IP access control, EDA-environment exposure and foundry data exchange, framed by trade-secret protection, NIST CSF and SOC 2. Delivered remotely from our Gulf base on a daily overlap window, with on-site work where it genuinely helps. Fixed price, audit-ready reporting, free retest.
// 01 Why Folsom businesses need penetration testing
A chip company's crown jewels are its designs. The RTL that describes the logic, the netlists synthesised from it, the verification and test data that prove it works, and the GDSII layout that finally goes to a foundry - together these are years of engineering a competitor or a well-resourced adversary would take in an afternoon if they could reach it. The loss is not measured in a regulatory fine; it is a roadmap arriving somewhere it was never meant to go.
Folsom concentrates exactly this work: large chip-design and engineering sites and the ecosystem of tool users, IP vendors and design-services firms around them. That value lives in an environment most attackers understand poorly and most defenders under-test - EDA toolchains on large compute and license farms, shared project storage, and a big population of engineers and contractors who need broad access to do their jobs. The failure mode is rarely a dramatic external breach. It is a design reaching someone it should not: an over-broad entitlement, a contractor account still live after a project ends, a repository clone onto an unmanaged laptop, an exchange portal that trusts a partner identifier it should verify.
Scanning does not find that class of problem. A scanner flags an unpatched host; it cannot tell you that an engineer on one project can read another team's GDSII, that a service account on the compute farm reaches the whole design store, or that a foundry portal lets a modified request pull down another customer's layout. Those are access decisions, and proving them takes a tester who understands both the attacker's mindset and how a design environment is actually built.
// 02 Compliance and regulatory drivers in Folsom
Design-security programmes here are anchored less to a single statute than to the business need to protect intellectual property, layered with the specific obligations that follow controlled work, supplier assurance and export-controlled technology.
Trade-secret & IP protection
Your designs are protectable as trade secrets only while you can show reasonable measures to keep them secret. Independent testing of who can reach and remove design data is direct evidence of those measures - and the most defensible framing for a chip-design programme.
NIST SP 800-171 & CMMC
Where a design supports defense or other controlled programmes, NIST SP 800-171 and CMMC set the safeguarding requirements for that data. Penetration testing evidences the access-control, boundary and assessment expectations those regimes carry.
EAR export-control awareness
Semiconductor design technology can be export-controlled under the EAR, which makes an unauthorised disclosure to a foreign party a compliance event as well as an IP loss. We flag findings where a design could reach an uncontrolled destination, as a light but deliberate note.
SOC 2, ISO 27001 & NIST CSF
IP and design-services vendors selling into larger chip companies face security review before contract. SOC 2 reports, ISO 27001 A.8.29 evidence and NIST CSF programmes all rest on independent testing of the environment holding customer design data.
Foundry & IP-partner NDAs
Foundries and IP vendors bind design exchange under NDA and often their own security schedules. We test whether the technical controls behind those agreements actually enforce them, rather than assuming the paperwork does.
CCPA / CPRA
California's consumer-privacy regime still applies to the workforce, contractor and business data a design firm holds, adding risk-assessment and cybersecurity-audit expectations across the non-design side of the business.
// 03 Penetration testing services for Folsom
Folsom engagements weight the design environment over the general perimeter, because that is where the value sits. Design-repository and code review lead, the compute-farm and cloud identity behind the toolchain follow, and the exchange interfaces with foundries and IP partners get tested as targets in their own right.
Design & source-code review
Access control and secrets exposure across RTL, netlists, build scripts and design repositories - who can read what, and what a clone actually carries out.
Cloud pen testing
Identity, tenant isolation, storage exposure and service-account scope across the cloud behind design infrastructure, artifact stores and elastic compute.
Network pen testing
External, internal and Active Directory testing, plus segmentation checks between the design environment, the compute/license farm and general corporate IT.
API pen testing
Foundry and IP-partner exchange portals and their APIs - broken object-level authorisation, scope enforcement and token handling on the interfaces that move designs.
Web application pen testing
Internal design-management, project and collaboration applications, tested against the OWASP Top 10 and the business-logic that gates design access.
Red teaming
Goal-based adversary and assumed-breach simulation aimed at a real objective: exfiltrating a seeded design without tripping detection.
// 04 How we deliver to Folsom
We will not pretend otherwise: CyberFortify is a Gulf-based firm on UTC+3, and Folsom sits ten to eleven hours behind us. We have no California office and no local staff. What we do have is a working pattern built around that gap: our late afternoon and evening is your morning, and we hold that window open daily for stand-ups, live triage and read-outs with your engineering and security leads. Testing continues while Folsom is offline, so confirmed findings are waiting when your day starts.
What runs remotely
Design-repository and code review, cloud, API, web and external testing from our secure environment - the large majority of design-IP and EDA scope, worked against seeded test designs, never your live crown-jewel data. Findings land in a shared channel as confirmed, criticals escalated immediately.
What we do on-site
Internal network, compute-farm and segmentation testing where a tester genuinely needs to be on the wire inside the design environment, plus workshops for security and engineering committees. We travel when it adds value and say so when it does not.
Every engagement opens with a free 30-minute scoping call and a fixed-price quote within the hour. For live design environments we agree test windows around tape-out schedules and compute load, and a free retest proves the fixes.
// 05 Industries we secure in Folsom
Folsom's risk profile is shaped by a dense concentration of chip-design work and the technology ecosystem that supports it.
// 06 Our methodology
Folsom engagements follow the same audit-defensible process we run everywhere, tuned to the design environment at the centre of this market. Testing is grounded in PTES and NIST SP 800-115, with exploitation mapped to MITRE ATT&CK tactics - especially collection and exfiltration - and application work driven by OWASP, including the API Security Top 10. As a CREST Accreditation Pathway firm we lead with manual testing; automation supports the tester, never replaces one.
Scoping & rules of engagement
Design repositories, EDA and farm surfaces, exchange interfaces, contractor-access boundaries, seeded test designs and escalation paths agreed in writing first.
Fixed quote in 1hReconnaissance & threat modelling
Attack surface mapped around the design itself - who can reach it, from which account, through which tool, and every path by which it could leave.
ATT&CK alignedManual exploitation
Weaknesses exploited and chained under controlled conditions from assumed-insider and assumed-breach positions, with cross-project and exfiltration paths proven using seeded design records - never live IP.
Controlled exploitReporting & free retest
Executive summary, CVSS-scored detail and mapping to trade-secret measures, NIST 800-171, SOC 2 or NIST CSF - plus a free retest once fixes ship.
Audit-ready// 07 Why CyberFortify for Folsom
A scan-and-report vendor
Automated output rebadged as a penetration test, blind to design-access logic, unable to reason about who an entitlement belongs to or which path actually lets a layout leave the building.
CyberFortify
A Gulf-based, CREST-pathway team candid about the time difference and structured around it. Manual exploitation aimed at design-IP exfiltration resistance, EDA-environment exposure and foundry exchange, findings mapped to your assessors' and customers' frameworks, fixed pricing and a free retest.
Folsom engagements most often pair a design and code review with a cloud penetration test, since design-IP risk splits between the access logic in front of the repositories and the identity and storage configuration underneath the compute farm. Where the concern is a determined insider or a quiet exfiltration, we add red teaming to test whether the design could leave without anyone noticing.
// 08 Frequently asked questions
How do you test access control and exfiltration risk around our RTL and GDSII design repositories?
We treat the design repository as the crown-jewel target and test it from an assumed-insider and assumed-breach position. We check who can reach RTL, netlists, testbenches and GDSII layouts, whether entitlements are enforced per project rather than granted broadly, and whether a contractor or compromised engineering account can read designs outside its assignment. Then we test the paths data could leave by - repository clones, artifact stores, build outputs, cloud sync and outbound channels - and prove which actually let a design escape versus which are only assumed blocked.
Can you assess our EDA toolchain and the compute and license farm behind it?
Yes. The design lives inside the EDA tools and on the compute and license infrastructure that runs them, so we test that environment directly. We look at how jobs are submitted and scheduled across the farm, whether shared scratch and project storage leaks design data between teams, how license servers and their service accounts are exposed, and whether the toolchain's automation and orchestration can be abused to reach data or hosts it should not. We also test the identity and segmentation that is meant to keep the design environment separate from general corporate IT.
How do you approach the data exchange with our foundry and third-party IP vendors?
We treat each exchange as its own target rather than assuming the NDA is the control. We test the portals and transfer mechanisms that move layouts to a foundry and pull licensed IP blocks in from partners: how the two sides authenticate, whether a partner or project identifier in a request can be changed to reach another party's data, whether download scopes and expiry are enforced, and whether credentials for these interfaces are over-scoped or shared. We test from the positions a real adversary would occupy, including a hostile trading partner and a compromised exchange account.
With your team in the Gulf, how does the time gap work for a Folsom engagement?
We should be plain: CyberFortify is a Gulf-based firm on UTC+3, ten to eleven hours ahead of Folsom, with no California office or local staff. We hold a deliberate daily overlap window - our late afternoon and evening is your morning - for stand-ups, live triage and read-outs with your engineering and security leads. Testing continues while your team is offline, so confirmed findings are usually waiting when your day begins.
Which standards and frameworks do you map a Folsom design-security engagement to?
The defensible business framing is trade-secret and IP protection - your designs are years of R&D and the loss is measured in stolen roadmaps, not fines. Where a design touches controlled or defense-related work, NIST SP 800-171 and CMMC apply, and export-control awareness matters for semiconductor technology under the EAR. On top of that, suppliers and partners expect SOC 2 evidence and many teams anchor the programme to NIST CSF. We map every finding to the frameworks your assessors and customers actually ask for.